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TITLE OF THE INVENTION 

SEMICONDUCTOR MEMORY CKBD , PLAYBACK APPl^RATUS, 
RECORDING APPARATUS, PLAYBACK METHOD, RECORDING METHOD, 
AND A COMPUTER-READABLE STORAGE MEDIUM 

5 

This application is based on application Nos . Hll-149893, 
Hll-236724, andHll-372605 filed in Japan, the contents of which 
is hereby incorporated by reference. 

10 BACKGROUND OF THE INVENTION 

1. Field of the Invention 

Ul The present invention relates to a semiconductor 

n memory card that stores audio data, still image data and 
g control data, and to a playback apparatus, recording 
"^^15 apparatus, playback method, recording method, and 
CI- computer-readable recording medium relating to such a 

semiconductor memory card* In particular, " the present 
Si invention relates to improved storage of audio data and 

control data distributed as contents by a content 
20 distribution service, such as an electronic music 

distribution service • 

2. Description of Background Art 

Electronic music distribution enables users to 
25 purchase and receive music contents (e.g., songs and albums) 
via the Internet. Such technology has the potential to 
greatly increase the market for recorded music and is 

1 



gradually becoming possible as the necessary hardware 
infrastructure is implemented. One way to store music 
contents that are obtained from an electronic music 
distribution service is on semiconductor memory cards whose 
5 portability makes them ideal. Accordingly^ a great 
increase is expected in the demand for such cards. 

Various kinds of semiconductor memory cards are 
available, such as Flash ATA cards and Compact Flash cards. 
Music contents can also be stored onto disc media, such 

10 as CD-R (Compact Disc-Recordable) or MiniDisc (MD) . While 
there are a great variety of recording media that can be 
used for recording music contents, there are only a limited 
number of methods for indicating where the playback of a 
music content (track) should start. This operation is 

15 generally performed according to one of the following 
patterns . 

When a music album is composed of a plurality of music 
contents (tracks) , there are two main methods for indicating 
where the playback should start. The first method has the 

20 playback start from the first track in the album. The second 
method has the user indicate a track number and then has 
the playback start from the beginning of the indicated track . 

In the first of these methods, the playback always 
starts with the same track and continues through all of 

25 the tracks in the album in the same order. If the user stops 
the playback midway through the album, recommencing the 
playback according to this method will result in the playback 



apparatus returning to the first track. The user will 
therefore end up having to listen to tracks that have just 
been played. 

In the second method^ the playback starts from the 
5 track indicated by the user. When the user stops *the 
playback at a given point in the album and then starts playback 
once again, the user can have the playback restart from 
any track, such as the track following the track where 
playback was stopped. This means that the user does not 

10 have to listen to the tracks from the start once more. In 
this latter case, however, the user will still have to make 
several operations, such as inputting a track number. This 
can be troublesome, especially if the user does not know 
which track corresponds to which track number . In such cases , 

15 the user may indicate the wrong track, which will then be 
played back by the playback apparatus . 

As described above, when playback is stopped and then 
recommenced, the two methods currently used either force 
the user to listen to all of the tracks in order from the 

20 beginning or to input a track number for the track from 
which the playback should start. This is far from ideal. 

The following two methods are also sometimes used to 
indicate a position at which playback should commence. A 
third method has the user indicate move the playback position 

25 to a desired start time within a desired track using a forward 
or backward search function provided by a playback apparatus . 
A fourth method has the user indicate a desired track and 
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a desired position within this track using a jog dial (or 
the like) and then comiuences reproduction from this position . 
Since bothmethods have the user indicate how far the playback 
previously progressed, they have the same drawback as the 
5 second method described above. 

Current MiniDisc (MD) playback apparatuses use a 
reproduction method that indicates the playback position 
in a more user-friendly manner than the first to fourth 
methods given above . 
10 When the user stops the playback of an MD, resume 

■;J information showing the position where playback stopped 
is recorded in a nonvolatile memory in the MD player. When 

a the user indicates playback of the same MD, the playback 

Q of the tracks recorded on the MD starts at the position 

'■^^15 given in the resume information, 

CI The resume information is recorded in the MD player 

111 in a nonvolatile manner so that an interruption to the power 
Pi' supply does not result in the loss of the information. This 
means that the user can listen to part of a music album, 
20 turn off the player, and still have the playback resume 
at the position where playback was stopped. In this case, 
the user does not have to repeatedly listen to the tracks 
at the start of the album as in the first method, or to 
have to input a track number as in the second method, making 
25 this an ideal way to listen to all of the tracks included 
in an album. 

With an MD, however, the resume information showing 

4 



how far an album has been played back is stored within the 
hardware of the MD player . Accordingly, there is the problem 
that when an MD is ejected from a player and inserted into 
another player, the second player will play back the tracks 
5 on the MD starting from the first track in the album, in 
the same way as the first method. 

As a specific example, when a user listens to some 
of the tracks on an album using a first playback apparatus, 
stops the playback, and then transfers the disc to another 

10 playback apparatus, this second playback apparatus will 
not store resume information showing the position reached 
by the playback of this disc. As a result, the playback 
will start from the start of the album and so make the user 
listen to the same tracks again. 

15 Since discs are rarely transferred from one player 

to another during the playback of an album, the playback 
returning to the start of the album may not be such a 
significant problem. When the album is subjected to 
electronic music distribution before being recorded onto 

20 a recording medium, however, it is believed that there will 
be many cases where an album will be partially played back 
on one player and then transferred to another. 

Electronic music distribution is achieved by having 
a computer owned by the user download a music album from 

25 a server computer operated by a record label. The user can 
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then have the downloaded albumplayedback on their computer . 
Since modern personal computers are capable of playing back 
music contents, users can listen to albums they have bought 
on their computer . Assume that the user listens to the album 
on a portable playback apparatus after listening to it on 
his/her computer. 

In this case, the portable playback apparatus cannot 
know how far playback by the computer progressed, so that 
the album will be played back once again from the start. 
As the user will be subjected to the same songs that were 
played back by the computer, the user is likely to tire 
of the album quicker than if all of the tracks were played 
back . 

As recording media become smaller and lighter, though 
larger in capacity, it becomes increasingly possible to 
record albums containing large numbers of tracks onto a 
single recording medium. It is believed that such a 
recording medium will often be transferred between playback 
apparatuses . If the playback returns to the beginning after 
a large number of tracks have been played, this will be 
very annoying for listeners. 
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SUMMARY OF THE INVENTION 

It is a first object of the present invention to provide 
a semiconductor memory card that enables playback to be 
resumed from a previously stopped position without the same 
5 recordedmaterial being played back and without a user having 
to indicate the playback position, even when the 
semiconductor memory card has been transferred between 
playback apparatuses . 

It is a second object of the present invention to 

10 provide a semiconductor memory card that enables a playback 
apparatus to recommence the playback of an album that was 
commenced on a different playback apparatus without the 
same recorded material being played back. 

The first object can be achieved by a semiconductor 

15 memory card, storing: an audio sequence in which a plurality 
of audio objects are arranged; and resume information 
showing a resume position for use when playback of the audio 
sequence resumes midway through the audio sequence. 

Assume that an audio sequence corresponds to a music 

20 album, and that the user listens to a first part of the 
album on a playback apparatus. If the user then transfers 
the semiconductor memory card to another playback apparatus , 
this playback apparatus will be able to recommence the 
playback of the album at the stopped position by referring 

25 to the playback resume position shown by the resume 
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information. 

The resumption of playback based on the resume 
information does not require the user to make any particular 
operation. This means that the user does not have to go 
5 to the trouble of indicating a track (audio object) when 
transferring the semiconductor memory card to another 
playback apparatus . 

The resume information may include at least one of 
type 1 position information and type 2 position information^ 

10 the type 1 position information showing a type 1 resume 
position set according to a user operation, and the type 
2 position information ^^showing a type 2 resume position 
that was automatically set when playback of the audio 
sequence last stopped. 

.15 Here, each audio object in the audio sequence may be 

provided with unique identification information, the type 
1 position information showing the type 1 resume position 
using the identification information of one of the audio 
objects, and the type 2 position information showing the 

20 type 2 resume position using the identification information 
of one of the audio objects and time information showing 
an offset from a start of the one of the audio objects to 
the type 2 resume position. 

The second ob j ect is achieved by the above construction . 

25 The type 2 position information includes an offset from 



8 



the start of an audio ob j ect . When the semiconductor memory 
card is transferredbetween playback apparatuses, the second 
playback apparatus can commence playback at a position 
immediately following a point where playback by the first 
5 playback apparatus was stopped. This means that a user can 
start to listen to an album on a first playback apparatus, 
stop the playback, transfer the semiconductor memory card 
to another playback apparatus, and then have the playback 
continue from right after the stopped position. Unlike 
10 conventional technologies, the user does not have to put 
up with hearing the same tracks whenever the semiconductor 
memory card is transferred between playback apparatuses. 

lis I ' 

^Q. Albums obtained from an electronic music distribution 

^^11 service will of ten be transferredbetween different playback 
i^l 15 apparatuses. In such case, however, the user will not have 
^ to listen to the same tracks whenever the album is transferred 
to another playback apparatus. 

BRIEF DESCRIPTION OF THE DRAWINGS 

20 These and other objects, advantages and features of 

the invention will become apparent from the following 
description thereof taken in conjunction with the 
accompanying drawings which illustrate a specific 
embodiment of the invention. In the Drawings: 

25 FIG. 1 shows the appearance of a flash memory card 
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31 when viewed from above; 

FIG. 2 shows the construction of the flash memory card 
31 when viewed from below; 

FIG. 3 shows the hierarchical composition of the flash 
memory card 31 in the embodiments; 

FIG. 4A shows the special region, the authentication 
region and the user region provided in the physical layer 
of the flash memory card 31; 

FIG. 4B shows the composition of the authentication 
region and the user region in the file system layer; 

FIG. 5 shows the detailed composition of the file system 
layer; 

FIG. 6 is a representation of when the AOB file 
"AOBOOl.SAl" is divided into five parts that are stored 
in clusters 003, 004, 005, OOA, and OOC; 

FIG. 7 shows one example of the settings of the 
directory entries and file allocation table when the AOB 
file "AOBOOl.SAl" is recorded in a plurality of clusters; 

FIGs. 8A and 8B show what directories are provided 
in the user region and the authentication region in the 
file system layer when the above two types of data are recorded 
in the application layer, as well as what kind of files 
are recorded in which directories; 

FIG. 9 shows the correspondence between the file 
"AOBSAl .KEY" and the AOB files in the SD Audio directories; 
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FIG* 10 shows the hierarchical composition of the data 
in an AOB file; 

FIG. IIA shows the parameters stipulated by ISO/IEC 
13818-7 standard in tabular form; 

FIG* IIB shows the parameters that should be used when 
encoding a file in MPEG-Layer 3 (MP3) format in tabular 
form; 

FIG. lie shows the parameters that should be used when 
encoding a file in Windows Media Audio (WMA) format in tabular 
form; 

FIG. 12 shows the detailed construction of an 
AOB__FRAME; 

FIG. 13 shows how the byte length of the audio data 
in each of three AOB_FRAMEs is set; 

FIG. 14 shows the correspondence between the 
sampling_f requency and the number of AOB_FRAMEs included 
in an AOB_ELEMENT; 

FIG. 15 shows examples of the playback periods of 
AOB_ELEMENTs and the playback periods of AOB_FRAMEs; 

FIG. 16 shows what is reproduced when the AOBs and 
AOB_BLOCKs recorded in an AOB file are consecutively played 
back; 

FIG. 17 shows the hierarchical composition of the 
PlaylistManager and TrackManager used in the embodiments 
in detail; 



FIG. 18 shows the sizes of the PlaylistManager and 
the TrackManager ; 

FIG. 19 shows the correspondence between the TKIs shown 
in FIG. 17 and the AOBs and AOB files shown in FIG. 16; 
5 FIG. 20 shows the detailed data composition of the 

TKTMSRT shown in FIG. 17; 

FIG. 21 shows one example of the TKTMSRT; 

FIG. 22 shows the detailed composition of the TKGI; 

FIGs . 23A and 23B show the composition of the BIT; 
10 FIG. 23C shows the Time_Length field; 

FIG. 24 shows cluster 007 to OOE into which the AOB 
composed of A0B_ELEMENT#1 to A0B_ELEMENT#4 are stored; 

FIG. 25 shows how the next AOB_FRAME#x+l to be played 
back is set when forward search is performed starting from 
15 the AOB_FRAME#x in an arbitrary AOB_ELEMENT#y in an AOB; 

FIGs. 26A and 26B shows how an AOB, an AOB_ELEMENT, 
and an AOB_FRAME that correspond to an arbitrary playback 
time code are specified; 

FIGS. 27A and 27B show the deletion of a track; 
20 FIG. 28A shows the TrackManager after the deletion 

of a track has been performed several times; 

FIG. 2 SB shows how a new TKI and AOB file are written 
when "Unused" TKIs are present in the TrackManager; 

FIGS. 29A and 29B show the TKIs are set when two tracks 
25 are combined to produce a new track; 
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FIG. 30A shows a Typel AOB; 
FIG. SOB shows Type2 AOBs; 

FIG. 31A shows the combining of a plurality of tracks 
into a single track for a combination of a Typel+ Type2+ 
Type 2+ Typel AOB; 

FIG. 31B shows the combining of a plurality of tracks 
into a single track for a combination of a Typel+ Type2+ 
Type2H- Type2+ Typel AOB; 

FIG. 32A shows a pattern where a Typel AOB is present 
at the end of a preceding track and a Typel AOB is present 
at the start of a next track; 

FIG. 32B shows a pattern where a Typel AOB is present 
at the end of a first track and a Type2 AOB is present at 
the start of a next track; 

FIG. 32C shows a pattern where a Typel and Type2 AOB 
are present at the end of a first track and a Typel AOB 
is present at the start of a next track; 

FIG. 32D shows a pattern where a Typel and Type2 AOB 
are present at the end of a first track and a Type2 and 
a Typel AOB is present at the start of a next track; 

FIG, 32E shows a pattern where two Type2 AOBs are 
present at the end of a first track and a Typel is present 
at the start of a next track; 

FIGS . 33A and 33B show the division of a track to produce 
two tracks; 
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FIGS. 34A and 34B show the content of the SD_Audio 
directory entries in the SD_Audio directory including the 
AOB file "AOB003.SA1" before and after the division of the 
track; 

FIG. 35A shows the division of an AOB midway through 
A0B__ELEMENT#2; 

FIG. 35B shows the two AOBs, AOB#l andA0B#2, obtained 
by dividing an AOB midway through A0B_ELEMENT#2 ; 

FIG, 3 6 shows how the BIT is set when an AOB is divided 
as shown in FIG. 35; 

FIG. 37 shows a specific example of changes in the 
BIT before and after division; 

FIG. 38 shows a specific example of changes in the 
TKTMSRT before and after division; 

FIG. 39A shows the format of a DPL_TK_SRP; 

FIG. 39B shows the format of a PL__TK_SRP; 

FIG, 40 shows the interrelation between the 
Def ault___Playlist__Inf ormation, the TKIs^. and the AOB files; 

FIG. 41 shows example settings for the 
Def ault__Playlist and several PLIs; 

FIG. 42 shows how the DPL__TK_SRPs correspond to TKIs 
using the same notation as FIG. 40; 

FIGS. 43A and 43B show how the order of tracks is 
rearranged; 

FIGS. 44A and 44B show how the Def ault_Playlist , 
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TrackManager^ and AOB files will be updated when 
DPL_TK_SRP#2 andTKI#2 are deleted from the Def ault_Playlist 
shown in FIG. 40; 

FIGS. 45A and 45B show how a new TKI and DPL_TK_SRP 
5 are written when an "Unused" TKI and DPL__TK_SRP are present; 
FIGS. 4 6A and 4 6B show how tracks are combined; 

FIGS. 47A and 478 shows how a track is divided; 

FIG. 4 8 shows the appearance of a portable playback 
apparatus for the flash memory card 31 of the present 
10 embodiments; 

FIG. 4 9 shows one example of the display on the LCD 
panel when a playlist is selected; 

FIGS. 50A to 50E show examples of the display on the 
LCD panel when a track is selected; 
15 FIGS. 51A to 51C show example operations of the jog 

dial; 

FIG. 52 shows the internal construction of the 
reproduction apparatus; 

FIG. 53 shows how data is transferred in and out of 
20 the double buffer 15; 

FIG. 54A and 54B shows how areas in the double buffer 
15 are cyclically allocated using ring pointers; 

FIG. 55 is a flowchart showing the AOB file read 
procedure; 

25 FIG. 56 is a flowchart showing the AOB file output 
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procedure; 

FIG* 57 is a flowchart showing the AOB file output 
procedure; 

FIG. 58 is a flowchart showing the AOB file output 
procedure; 

FIGS. 59A to 59D show how the playback time code 
displayed in the playback time code frame on the LCD panel 
5 is updated in accordance with the updating of the variable 
Play_time; 

FIG. 60 is a flowchart shows the processing of the 
CPU 10 when the forward search function is used; 

FIGS. 61A to 61D show how the playback time code is 
incremented when the forward search function is used; 

FIGS. 62A and 62B show specific examples of how the 
time search function is used; 

FIG. 63 is a flowchart showing the processing in the 
editing control program; 

FIG. 64 is a flowchart showing the processing in the 
editing control program; 

FIG. 65 is a flowchart showing the processing in the 
editing control program; 

FIG. 66 shows one example of a recording apparatus 
for recording data onto the flash memory card 31; 

FIG. 67 shows the hardware configuration of the 
recording apparatus ; 
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FIG. 68 is a flowchart showing the processing during 
recording; 

FIG. 69 shows the internal composition of the 
PlaylistManager and TrackManager in the second embodiment; 
5 FIG. 7 0 shows the detailed composition of the 

PlaylistManager_Inf ormation; 

FIG. 71 shows how the PLMG_AP_PL and PLMG_RSM_PL are 
set when the flash memory card of the second embodiment 
is transferred between a plurality of playback apparatuses; 
10 FIG. 72 shows the menu screen used to receive a user 

setting of the PLMG__AP__PL and the activation setting; 

FIG. 73 is a flowchart showing the playback position 
determining procedure performed based on the PLMG__AP_PL 
and the PLMG_RSM_PL; 
15 FIG. 74 shows the data construction used when the upper 

six bytes of the PLI_RSM__PL (DPLI_RSM_PL) are stored in 
the DPLGI for the DPLI and in the PLGI for a PLI; 

FIG. 75 shows how the PLI_RSM_PL (DPLI_RSM_PL) is set 
for the Default__Playlist_Inf ormation and each PLI; 
20 FIG. 7 6 shows the track sequences composed of the 

playback orders indicated by the playlists shown in FIG. 
41 referred to by the first embodiment; 

FIG. 77 shows one example of a menu screen that shows 
each playlist together with the setting of the PLI__RSM_PL 
25 for a case where the playback ranges (1) to (3) in FIG. 
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7 6 have been already played back; and 

FIG. 78 shows the data format of the DPLGI, PLGI, TKGI 
in the fourth embodiment of the present invention. 

5 DESCRIPTION OF THE PREFERRED EMBODIMENTS 

The following describes a semiconductor memory card 
(flash memory card) that is an embodiment of the present 
invention^ with reference to the attached figures. 

The following paragraphs are arranged into a hierarchy 
10 using reference numbers with the notation given below. 

{xl-x2_x3"x4 } 

The length of a reference number shows the level of 
15 the topic in the hierarchy. As a specific example, the 
number xl is the number of drawing that is being referred 
to in the explanation. The drawings attached to this 
specification have been numbered in the order in which they 
are referred to in the specification, so that the order 
20 of the drawings roughly matches the order of the explanation . 
The explanation of certain drawings has been divided into 
sections, with the reference number x2 giving the section 
number of a section in the explanation of a drawing indicated 
by the reference number xl. The reference number x3 shows 
25 the number of an additional drawing that is provided to 
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show the details of the section indicated by the section 
number x2 . Finally, the reference number x4 shows the number 
of a section in the explanation of this additional drawing. 

5 FIRST EMBODIMENT 

{1-1_2} External Appearance of the Flash Memory Card 31 

The present explanation starts with the external 
appearance of the flash memory card 31. FIG. 1 shows the 
appearance of the flash memory card 31 when viewed from 

10 above, while FIG. 2 shows the construction of the flash 
memory card 31 when viewed from below. As shown in FIGS. 
1 and 2f the flash memory card 31 is around the same size 
as a postage stamp, and so is large enough to be held by 
hand. Its approximate dimensions are 32.0mm long, 24.0mm 

15 wide, and 2.0mm thick. 

The flash memory card 31 can be seen to have nine 
connectors on its bottom edge for connecting the card to 
a compatible device and a protect switch 32 on one side 
to enable the user to set whether overwriting of the stored 

20 content of the flash memory card 31 is permitted or 
prohibited. 

{3-1} Physical Construction of the Plash Memory Card 31 

FIG. 3 shows the hierarchical structure of the 
25 semiconductor memory card (hereafter referred to as the 
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"flash memory card 31" ) of the present embodiment . As shown 
in FIG. 3, the flash memory card 31 is constructed with 
a physical layer, a file system layer and an application 
layer in the same way as a DVD (Digital Video Disc) , though 
5 the logical and physical constructions of these layers are 
very different to those on a DVD. 

{3-2} Physical Layer of the Flash Memory Card 31 

The following describes the physical layer of the flash 
10 memory card 31 . The flash memory is composed of a plurality 
of sectors^ each of which stores 512 bytes of digital data. 
As one example, a 64MB flash memory card 31 will have a 
storage capacity of 67,108,864 (=64^1,024*1,024) bytes, 
so that this card will include 131, 072 (-67108864/512) valid 
15 sectors. Once the number of 

replacement sectors, which are provided for use in case 
of errors, is subtracted, the remaining number of valid 
sectors into which various kinds of data can be written 
is around 128, 000 . 

20 

{3-2_4A-l} Three Regions in the Physical Layer 

The three regions shown in FIG. 4A are provided in 
the storage area composed of these valid sectors. These 
regions are the "special region", the "authentication 
25 region" and the "user region", and are described in detail 
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below. The user region is characterized in that a device 

to which the flash memory card 31 is connected can freely 
read or write various kinds of data from or into this region . 
Areas within the user region are managed by a file system. 
5 The special region stores a media ID that is a value 

uniquely assigned to each flash memory card 31. Unlike the 
user region, this region is read-only, so that the media 
ID stored in the special region cannot be changed. 

The authentication region is a writeable region, like 

10 the user region. This region differs from the user region 
in that a device connected to the flash memory card 31 can 
access (i.e., read or write data in) the authentication 
region only if the flash memory card 31 and the device have 
first confirmed that each other is an authentic device. 

15 In other words, data can only be read from or written into 
the authentication region if mutual authentication has been 
successfully performed by the flash memory card 31 and the 
device connected to the flash memory card 31. 

20 {3"2_4A"2} Uses of the Three Regions 

in the Physical Layer 

When the device connected to the flash memory card 
31 writes data into the flash memory card 31, the region 
used to store this data will depend on whether copyright 
25 protection is necessary for the data being written. When 
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data that requires copyright protection is written into 
the flash memory card 31, the data is encrypted using a 
predetermined encryption key {called a "FileKey") before 
being written into the user area • This FileKey can be freely 
5 set by the copyright holder and, while the use of this FileKey 
provides some level of copyright protection, the FileKey 
used for encrypting the written data is itself encrypted 
to make the copyright protection more secure. Any value 
obtained by subjecting the media ID stored in the special 

10 region into a predetermined calculation can be used to 
encrypt the FileKey . The encrypted FileKey produced in this 
way is stored in the authentication region. 

Since data that requires copyright protection is 
subjected to a two-step encryption process where the data 

15 is encrypted using a FileKey that is itself encrypted based 
on the media ID, copyright infringement, such as the 
production of unauthorized copies of this data, will be 
extremely difficult, 

20 {3-2_4B-l} Overview of the File System 

As can be understood, the construction of the physical 
layer of the flash memory card 31 strengthens the copyright 
protection of the data written in the flash memory card 
31. The following describes the file system layer present 
25 on this physical layer. While the file system layer of a 
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DVD uses a UDF (Universal Disk Format) -type file system, 
the file system layer of the flash memory card 31 uses a 
FAT (File Allocation Table) -type file system, as described 
in ISO/IEC 9293. 

FIG. 4B shows the construction of the authentication 
region and the user region in the file system layer. As 
shown in FIG. 4B, the authentication region and the user 
region in the file system each include "partition boot 
sectors", a "file allocation table (FAT)", a "root 
directory", and a "data region", meaning that the 
authentication region and the user region have the same 
construction. FIG. 5 

shows the various parts of these file systems in more detail . 
The following describes the construction of the user region 
with reference to FIGS. 4A, 4B and 5. 
{3-2_^4B-2} Partition Boot Sectors 

The partition boot sectors are sectors that store the 
data that will be referred to by a standard personal computer 
that is connected to the flash memory card 31 when the flash 
memory card 31 is set as the boot disk for the operating 
system (OS) of the personal computer. 

{3-2_4B-3_5} Data Region 

The data region can be accessed by a device connected 
to the flash memory card 31 in units no smaller than a 
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"cluster". While each sector in the flash memory card 31 
is 512 bytes in size, the cluster size is 16KB, so that 
the file system layer reads and writes data in units of 
32 sectors. 

5 The reason the cluster size is set at 16KB is that 

when data is written onto the flash memory card 31, part 
of the data stored in the flash memory card 31 first has 
to be erased before the write can be performed. 

The smallest amount of data that can be erased in the 

10 flash memory card 31 is 16KB, so that setting the smallest 
erasable size as the cluster size means that data writes 
can be favorably performed. The arrow ff2 drawn using a 
broken line in FIG. 5 shows the plurality of clusters 
002,003,004,005 . . . included in the data region. The 

15 numbers 002,003,004,005,006,007,008 . . . used in FIG. 
5 are the three-digit hexadecimal cluster numbers that are 
exclusively assigned to identify each cluster. Since the 
smallest unit by which access can be performed is one cluster, 
storage positions within the data region are indicated using 

20 cluster numbers. 

{3-2_4B-4_5} File Allocation System 

The file allocation system has a file system 
construction in accordance with ISO/IEC 9293 standard, and 
25 so is made up of a plurality of FAT values. Each FAT value 
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corresponds to a cluster and shows which cluster should 
be read after the cluster corresponding to the FAT value. 
The arrow ffl shown by a broken line in FIG. 5 shows the 
plurality of FAT values 002,003^004,005 . . . that are 
included in the file allocation table. The numbers 
002,003, 004, 005 . . . assigned to each FAT value show which 
cluster corresponds to each FAT value and therefore are 
the cluster numbers of the clusters corresponding to the 
FAT values. 

{3-2_4B-5_5-l} Root Directory Entries 

The "root directory entries" are information showing 
what kinds of files are present in the root directory. As 
specific examples, the "filename" of an existing file, its 
"filename extension", the "revision time/date" and "number 
of first cluster in file" showing where the start of the 
file is stored can be written as the root directory entry 
of a file. 

{3-2_4B-5_5-2} Directoary Entries for Svibdirectories 

Information relating to files in the root directory 
is written as root directory entries, though information 
relating to subdirectories is not written as the root 
directory entries. Directory entries for subdirectories 
are instead produced in the data region. In FIG, 5, the 
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SD-Audio directory entry given in the data region is one 
example of a directory entry for a subdirectory. Like a 
root directory entry, an SD-Audio directory entry includes 
the "filename" of a file present in this subdirectory, its 
5 "filename extension", the "revision time/date" and "number 
of first cluster in file" showing where the start of the 
file is stored, 

{3-2_4B-5_6-l} Storage Format for AOB Piles 

10 The following describes the file storage method by 

showing how a file named "AOBOOl.SAl" is stored in the 
SD-Audio directory, with reference to FIG. 6. Since the 
smallest unit by which the data region can be accessed is 
one cluster, the file "AOBOOl.SAl" needs to be stored in 

15 the data region in parts that are no smaller than one cluster . 
The file "AOBOOl.SAl" is therefore stored having first been 
divided into clusters. In FIG. 6, the file "AOBOOl.SAl" 
is divided into five parts in keeping with the cluster size, 
and the resulting parts are stored into the clusters numbered 

20 003, 004, 005, OOA, and OOC. 

{3-2_4B-5_7"l} Storage Format for AOB Files 

When the file "AOBOOl.SAl" is divided up into parts 
and stored, a directory entry and the file allocation table 
25 need to be set as shown in FIG. 7. FIG. 7 shows one example 
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of how the directory entry and file allocation table need 
to be set when the file "AOBOOl.SAl" is stored having been 
divided up into parts and stored. In FIG. 1 , the start of 
the file "AOBOOl.SAl" is stored in cluster 003, so that 
5 cluster number 003 is written into "the number of first 
cluster in file" in the SD-Audio directory entry to indicate 
the cluster storing the first part of the file. As shown 
in FIG. 1, the following parts of the file "AOBOOl.SAl" 
are stored in clusters 004 and 005. As a result, while the 

10 FAT value 003(004) corresponds to cluster 003 that stores 
the first part of the file "AOBOOl . SAl", this value indicates 
cluster 004 as the cluster storing the next part of the 
file "AOBOOl.SAl". In the same way, while the FAT values 
004 (005) and 005 (OOA) respectively correspond to clusters 

15 00 4 and 005 that store the next parts of the file "AOBOOl . SAl" , 
these values respectively indicate cluster 005 and cluster 
OOA as the clusters storing the next parts of the file 
"AOBOOl.SAl". By reading the clusters with the cluster 
numbers written into these FAT values in order as shown 

20 by the arrows fkl, fk2, fk3, fk4, fk5 ... in FIG. 7, 
all of the parts produced by dividing the file "AOBOOl.SAl" 
can be read. As explained above, the data region of the 
flash memory card 31 is accessed in units of clusters, each 
of which is associated with a FAT value. Note that the FAT 

25 value that corresponds to the cluster storing the final 
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part of an AOB file (the cluster OOC in the example shown 
in FIG. 7) is set the cluster number FFF to show that the 
corresponding cluster stores the final part of a file. 

This completes the explanation of the file system in 
5 the flash memory card 31 of the present invention. The 
following describes the application layer that exists on 
this file system. 

{3-3} Overview of the Application Layer 
10 In the Flash Memory Card 31 

An overviewof the application layer in the f lashmemory 
card 31 is shown in FIG. 3. As shown by the arrow PN2 drawn 
with a broken line in FIG. 3, the application layer in the 
flash memory card 31 is composed of presentation data and 

15 navigation data that is used to control the playback of 
the presentation data. As shown by the arrow PN2, the 
presentation data includes sets of audio objects (AOB sets) 
that are produced by encoding audio data that represents 
music^r for example. The navigation data includes a 

20 "PlaylistManager" (PLMG) and a "TrackManager" (TKMG) . 

{3"3_8A,B-1} Directory Composition 

FIGS. 8A and 8B show what kind of directories are 
present in the user region and the authentication region 
25 in the file system layer when these two types of data are 
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stored in the application layer, as well as showing what 
files are arranged into these directories . 

The filenames "SD__AUDIO . PLM" and "SD_AUDIO,TKM" in 
FIG. 8A indicate the files in which the PlaylistManager 
(PLMG) and TrackManager (TKMG) composing the navigation 
information are stored. Meanwhile, the filenames 
" AOB 0 0 1 . S Al " , " AOB 002. S Al " , " AOB 003. S Al " , 
"AOB004 .SAl", . . . indicate the files ("AOB" files) 
storing the audio objects that are the presentation data. 
The letters "SA" in the filename extension of the filename 
"AOBOxx.SAl" are an abbreviation for "Secure Audio", and 
show that the stored content of this file requires copyright 
protection. Note that while only eight AOB files are shown 
in the example in FIG. 8A, a maximum of 999 AOB files can 
be stored in an SD-Audio directory. 

When copyright protection is required for presentation 
data, a subdirectory called an "SD-Audio directory" is 
provided in the authentication region and an encryption 
key storing file "AOBSAl.KEY" is produced in this SD-Audio 
directory. 

FIG. 8B shows the encryption key storing file 
"AOBSAl.KEY" that is Stored under the "SD-Audio" legend 
(i.e., within the "SD-Audio directory") . This encryption 
key storing file "AOBSAl.KEY" stores a sequence of 
encryption keys that is produced by arranging a plurality 
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of encryption keys into a predetermined order. 

The SD-Audio directory shown in FIGS. 8A and 8B is 
stored in a server computer managed by a record label that 
uses electronic music distribution • When a consumer orders 
a music content^ the corresponding SD-Audio directory is 
compressed, encrypted and transmitted to the consumer via 
a public network. The consumer's computer receives this 
SD-Audio directory, decrypts it, decompresses it and so 
obtains the original SD-Audio directory. Note that the 
expression "public network" here refers to any kind of 
network that can be used by the public, such as a wired 
communication network, e.g., an ISDN network, or a wireless 
communication network, e.g., a mobile telephone system. 
It is also possible for a consumer's computer to download 
an AOB file from a server computer operated by a record 
label and then produce an SD-Audio directory, such as that 
shown in FIGS. 8A and SB, in the flash memory card 31. 

{3-3_9"l} Correspondence between the 

"AOBSAl.KEY" file and the AOB files 

FIG. 9 shows the correspondence between the 
"AOBSAl.KEY" file in the SD-Audio directory and the AOB 
files . The FileKeys used when encrypting files in the user 
region shown in FIG. 9 are stored in the corresponding 
encryption key storing file in the authentication region. 
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The encrypted AOB files and the encryption key storing 
file correspond according to the predetermined rules (1) , 
(2), and (3) described below. 

(1) The encryption key storing file is arranged into 
5 a directory with the same directory name as the directory 

in which the encrypted file is stored. In FIG. 9, AOB files 
are arranged into the SD-Audio directory in the user region 
and the encryption key storing file is arranged into a 
directory called the SD-Audio directory in the 
10 authentication region, in accordance with this rule. 

(2) The encryption key storing file is given a filename 
producedby combining the first three letters of the filename 
of the AOB files in the data region with the predetermined 
".key" extension. When the filename of an AOB file is 

15 "AOBOOl . SAl" , the encryption key storing file is given the 
filename "AOBSAl.KEY" produced by adding the first three 
characters "AOB";^ "SAl"^ and the extension ".key", as shown 
by the arrows nkl and nk2 in FIG. 9. 

(3) The filename of an AOB file is given a serial number 
20 showing the position of the FileKey corresponding to this 

audio object in the sequence of encryption keys given in 
the encryption key storing file. 

The "File Key Entries #1, #2, #3 . . . #8" show the 
first positions of the regions in which the respective 
25 FileKeys in the encryption key storing file are stored. 
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Meanwhile, the filenames of AOB files are assigned the serial 

numbers "001", "002", "003", "004" These serial 

numbers show the positions of the corresponding FileKeys 
in the encryption key sequence, so that the FileKey that 
5 was used to encrypt each AOB file will be present in the 
"FileKey Entry" with the same serial number. In FIG. 9, 
the arrows Akl, Ak2, Ak3, . • • show the correspondence 
between AOB files and FileKeys. In other words, the file 
"AOBOOl.SAl" corresponds to the FileKey whose storage 

10 position is indicated by the "FileKey Entry#l", the file 
"AOB002.SA1" corresponds to the FileKey whose storage 
position is indicated by the "FileKey Entry#2", and the 
file "AOB003.SA1" corresponds to the FileKey whose storage 
position is indicated by the "FileKey Entry#3". As can be 

15 understood from rule (3) , different FileKeys are used to 
encrypt different AOB files, with these FileKeys being 
stored in "FileKey Entries" with the serial numbers "001", 
"002", "003", "004" etc., given in the filenames of the 
corresponding AOB files. 

20 Since each AOB file is encrypted using a different 

FileKey, the exposure of the encryption key used for one 
AOB file will not enable users to decrypt other AOB files. 
This means that when AOB files are stored in an encrypted 
form on a flash memory card 31, the damage caused by the 

25 exposure of one FileKey can be minimized. 
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{3"3_10-1} Internal Composition of an AOB file 

The following describes the internal composition of 
an AOB file. FIG. 10 shows the hierarchical data structure 
5 of an AOB file. The first level in FIG, 10 shows the AOB 
file, while the second level shows the audio object (AOB) 
itself. The third level shows the AOB_BLOCKs, the fourth 
level an AOB_ELEMENT, and the fifth level an AOB_FRAME. 
The AOB_FRAME on the fifth level in FIG. 10 is the 

10 smallest unit composing the AOB, and is composed of audio 
data in ADTS (Audio Data Transport Stream) format and an 
ADTS header. Audio data in ADTS format is encrypted 
according to MPEG2-AAC (Low Complexity Profile) format and 
is stream data that can be played back at a transfer rate 

15 of 16Kbps to 144Kbps. Note that the transfer rate for PCM 
(Pulse Code Modulation) that is recorded on a conventional 
compact disc is 1.5Mbps, so that data in ADTS format generally 
uses a lower transfer rate than PCM. The data construction 
of a sequence of AOB_FRAMEs is the same as the sequence 

20 of audio frames included in an audio data transport stream 
distributed by an electronic music distribution service. 
This means that the audio data transport stream to be stored 
as AOB_FRAME sequence is encoded according to MPEG2-ACC 
standard, encrypted, and transmitted on a public network 

25 to the consumer. AOB files are produced by dividing the 
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transmitted audio data transport stream into a sequence 
of AOB_FRAMEs and storing these AOB_FRAMEs. 

{3"3_10-1_11} MPEG2-AAC 

MPEG2-AAC is described in detail in ISO/IEC 
13818-7 : 1997 (E) "Information Technology - Generic Coding 
of Moving Pictures and Associated Audio Information - Part7 
Advanced Audio Coding (AAC)", 

It should be noted that audio objects can only be 
compressed according to MPEG2-AAC using the parameters in 
the parameter table shown in FIG. IIA that is defined in 
ISO/IEC13818-7 . This parameter table is composed of 
"Parameter" column, a "Value" column, and a "Comment" 
column . 

The legend "profile" in the Parameter column shows 
the only LC-prof ile can be used, as stipulated under ISO/IEC 
13838-7. The legend "sampling_f requency#index" in the 
Parameter column shows that the sampling frequencies "48kH2, 
44.1kHz, 32kHz, 24kHz, 22.05kHZ, and 16kHz" can be used. 

The legend "number___of_data__block_in_f rame" in the 
Parameter column shows that the ratio of one header to one 
raw_data__block is used. 

Note that while this explanation describes the case 
where AOB_FRAMEs are encoded according to MPEG-AAC format, 
AOB_FRAMEs may instead be encoded according to another 
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format, such as MPEG-Layer3 (MP3) format or Windows Media 
Audio (WMA) . When doing so, the parameters shown in the 
parameter tables of FIG. IIB or FIG. IIC must be used. 

5 {3-3_10-2_12} Composition of an AOB_FRMdE 

While each AOB_FRAME includes audio data that is 
encoded according to the restrictions described above, the 
data length of the audio data in each AOB_FRAME is restricted 
to a playback time of only 20ms. However, since MPEG2-AAC 

PI 10 is a variable bitrate (VBR) encoding method, the data length 
of the audio data in each AOB_FRAME will vary . The following 

JjJ describes the composition of an AOB_FRZ\ME, with reference 

f to FIG. 12. 

^fl The first level in FIG . 12 shows the overall composition, 

pl5 while the second level shows how each part of an AOB__FRAME 
Sj is encrypted. As can be seen from the drawing, the ADTS 
header corresponds to a non-encrypted part. The audio data 
B includes both an encrypted part and a non-encrypted part. 
The encryptedpart of the audio data is composed of a plurality 
20 of eight-byte pieces of encrypted data, each of which is 
produced by encrypting an eight-byte piece of audio data 
using a 56~bit FileKey. When encryption is performed on 
64-bit pieces of audio data, the non-encrypted part of the 
audio data is simply a final part of the data that cannot 
25 be encrypted due to it being shorter than 64 bits. 
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The third level in FIG. 12 shows the content of the 
ADTS header that is in the non-encrypted part of the AOB__FRAME . 
The ADTS header is seven bytes long^ and includes a 12-bit 
synch word (set at FFF) , the data length of the audio data 
5 in this AOB^FRAME, and the sampling frequency used when 
the audio data was encoded. 

{3-3_10"3_13} Setting of the Byte Length of an AOB_FRAME 

FIG. 13 shows how the byte length of the audio data 
10 in each of three AOB_FRAMEs is set. In FIG. 13, the data 
length of audio data#l included in A0B_FRAME#1 is xl, the 
data length of audio data#l included in A0B_FRAME#2 is x2, 
and the data length of audio data#l included in A0B_FRAME#3 
isx3. When the data lengths xl, x2, and x3 are all different , 
15 the data length xl will be written in the ADTS header of 
A0B__FRAME#1, the data length x2 will be written in the ADTS 
header of A0B___FRAME#2 , and the data length x3 will be written 
in the ADTS header of A0B_FRAME#3. 

Although the audio data is encrypted, the ADTS header 
20 is not, so that a playback device can know the data length 
of the audio data in an AOB_FRAME by reading the data length 
given in the ADTS header of the AOB__FRAME. 

This completes the explanation of an AOB_FRAME. 

25 
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{ 3 " 3_1 0 - 4 } AOB_ELEMENT 

The following describes the AOB_ELEMENT shown on the 
fourth level in FIG. 10. 

An "AOB_ELEMENT" is a group of consecutive AOB_FRAMEs . 
The number of AOB_FRAMEs in an AOB_ELEMENT depends on the 
value set as the sampling__f requency_index shown in FIG. 
llA and the encoding method used. The number of AOB_FRAMEs 
in an AOB___ELEMENT is set so that the total playback time 
of the included AOB_FRAMEs will be around two seconds;, with 
this number depending on the sampling frequency and encoding 
method used. 

{3-3_10-5_14} Ntunber of AOB_FRAMEs in an AOB_ELEMENT 

FIG. 14 shows the correspondence between the sampling 
frequency and the number of AOB_FRAMEs included in an 
AOB__ELEMENT . The number N given in FIG. 14 represents the 
playback period of an AOB__ELEMENT in seconds . WhenMPEG-ACC 
is used as the encoding method, the value of N is "2". 

When the sampling_f requency is 4 8kHz, the number of 
AOB_FRAMEs included in an AOB_ELEMENT is given as 94 (=47*2) , 
while when the sampling_f requency is 44.1kHz, the number 
of AOB_FRAMEs included in an AOB^ELEMENT is given as 
86 (=43*2). When the sampling_f requency is 
32kHz, the number of AOB_FRAMEs is given as 64 (=32*2) , when 
the sampling__f requency is 24kHz, the number of AOB_FRAMEs 
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is given as 4 8 (=2 4*2) , when the sampling_f requency is 
22,05kHz, the number of AOB_FRAMEs is given as 44(-22*2), 
and when the sampling_f requency is 16kHz, the number of 
AOB_FRAMEs included in an AOB_ELEMENT is given as 32 ( = 16*2) , 
5 However, when an editing operation, such as the division 
of an AOB, has been performed, the number of AOB_FR?\MEs 
included in an AOB_ELEMENT at the start or end of an AOB 
may be less than a number calculated in this way. 

While no header or other special information is 
10 provided for each AOB_ELEMENT, the data length of each 
AOB__ELEMENT is instead shown by a time search table. 

{3-3_10-6_15} One Example of the 

Playback Periods of AOB_ELEMENTs and AOB^PRAMEs 

15 FIG. 15 shows one example of the playback periods of 

AOB_ELEMENTs and AOB_FRAMEs . The first level in FIG. 15 
shows a plurality of AOB__BLOCKs, while the second level 
shows a plurality of AOB_ELEMENTs . The third level shows 
a plurality of AOB__FRAMEs . 

20 As shown in FIG. 15^ an AOB__ELEMENT has a playback 

period of around 2.0 seconds, while an AOB_FRAME has a 
playback period of 20 milliseconds. The "TMSRT__entry" 
given to each AOB_ELEMENT shows that the data length of 
each AOB_ELEMENT is given in the time search table. By 

25 referring to the TMSRT_entries, a playback apparatus can 
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perform a forward or backward search where, for example, 
intermittent bursts of music are played back by repeatedly 
playing back 240 milliseconds of audio data and then skipping 
two seconds of audio data in the desired direction, 

5 

{ 3"3_10-7 } AOB_BLOCK 

This completes the explanation of an A0B_ELEME1SIT . The 
following describes the concept of the AOB_BLOCKs shown 
on the third level of the data construction of an AOB file 

10 given in FIG. 10. 

Each "AOB_BLOCK" is composed of valid AOB__ELEMENTs . 
Only one AOB__BLOCK exists in each AOB_FILE. While an 
AOB_ELEMENT has a playback period of around two seconds, 
an AOB_BLOCK has a maximum playback period of 8 . 4 minutes . 

15 The 8.4 minute limitation is imposed to restrict the size 
of the time search table to 504 bytes or less. 

{3-3_10"8} Restriction of the Time Search Table 

The following describes in detail why the size of the 
20 time search table is restricted by limiting the playback 
period. 

When a playback apparatus performs a forward or 
backward search, the playback apparatus skips the reading 
of two seconds of audio data before playing back 240 
25 milliseconds. When skipping two seconds of data, the 
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playback apparatus could in theory refer to the data lengths 
shown in the ADTS headers of AOB_FRAMEs, though this would 
mean that the playback apparatus would have to consecutively 
detect 100 (2 seconds/20 milliseconds) AOB_FRAMEs just to 
5 skip two seconds of audio data. This would amount to an 
excessive processing load for the playback apparatus. 

To reduce the processing load of a playback apparatus, 
the read addresses for data at two-second intervals can 
be written into a time search table that is then referred 

10 to by the playback apparatus when performing a forward or 
backward search. By writing information that enables read 
addresses that are two or four seconds ahead or behind to 
be found quickly into the time search table ( such information 
being the data sizes of AOB_ELEMENTs) ^ a playback apparatus 

15 will only need to refer to this information when performing 
a forward or backward search. The data size of audio data 
with a playback period of two seconds will depend on the 
bitrate used when playing back the audio data. As stated 
earlier, a bitrate in the range of 16Kbps to 144Kbps is 

20 used, so that the amount of data played back in two seconds 
will be in a range from 4KB (=16Kbps x 2/8 ) to 36KB (=144Kbps 
X2/8) . Since the amount of data played back in two seconds 
will be in a range from 4KB to 3 6KB, the data length of 
each entry in the time search table for writing the data 

25 length of audio data needs to be two bytes (=16 bits) long. 
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This is because a 16-bit value is capable of expressing 
a number in the range 0-64KB, 

On the other hand, if the total data size of the time 
search table needs to be restricted to 504 bytes (this being 
the data size of the TKTMSRT described later) , for example, 
the maximum number of entries in the time search table can 
be calculated as 504/2-252. 

Since an entry is provided every two seconds, the 
playback time corresponding to this maximum of 252 entries 
is 504 seconds (=2s*252), or, in other words, 8 minutes 
and 24 seconds (=8.4 minutes) . This means that setting the 
maximum playback period for an AOB_BLOCK at 8.4 minutes 
limits the data size of the time search table to 504 bytes. 

{3-3_10-9} Regarding AOBs 

This concludes the description of AOB_BLOCKs . The 
following describes AOBs. 

The AOBs shown on the second level of FIG . 10 are regions 
that have invalid areas at either end. Only one AOB is 
present in each AOB file. 

The invalid areas are regions that are read and written 
along with the AOB_BLOCKs and are stored in the same clusters 
as the AOB_BLOCKs. The start and end position of the 
AOB_BLOCKs within an AOB are shown by BITs included in the 
navigation data. These BITs are described in detail later 
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in this specif ication* 

This completes the explanation of what data is stored 
in an AOB file . The following describes what kind of content 
is played back when the eight AOBs and AOB_BLOCKs shown 
5 in the AOB file in FIG. 9 are successively read. 

{3"3_10-10_16} 

FIG. 16 shows the playback content when the AOBs and 
AOB_BLOCKs in this AOB file are successively read. The first 

10 level in FIG. 16 shows the eight AOB files in the user region, 
while the second level shows the eight AOBs recorded in 
these AOB files . The third level shows the eight AOB_BLOCKs 
included in these AOBs. 

The fifth level shows the titles of five contents 

15 composedby these AOB files . In this example, the "contents" 
are the five songs SongA, SongB, SongC, SongD, and SongE, 
while the "title" is a music album composed of these five 
songs. The broken lines ASl, ASl, AS3, . . . AS7, and 
ASS show the correspondence between the AOB_BLOCKs and the 

20 parts into which the album is divided, so that the fourth 
level in FIG. 16 shows the units used to divide the music 
album shown on the fifth level. 

By referring to the broken lines, it can be seen that 
the AOB_BLOCK included in A0B#1 is a song (SongA) with a 

25 playback period of 6.1 minutes. The AOB_BLOCK included in 
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A0B#2 is a song (SongB) with a playback period of 3 . 3 minutes . 
The AOB_BLOCK included in A0B#3 is a song (SongC) with a 
playback period of 5.5 minutes. In this way, "AOBOOl.SAl" 
to "AOB003.SA1" each correspond to a different song. The 
5 sixth level of FIG. 16 is a track sequence composed of tracks 
TrackA to TrackE. These tracks TrackA-TrackE correspond 
to the five songs SongA^ SongB, SongC, SongD, and SongE, 
and are each treated as a separate playback unit. 

On the other hand, A0B#4 has a playback period of 8 . 4 
Q 10 minutes and is the first (or "head") part of the song SongD 
JtJ that has a playback period of 30.6 minutes . The AOB__BLOCKs 
Jii included in AOB#5 and A0B#6 are middle parts of the song 
^JJ SongD and also have playback periods of 8.4 minutes. The 
=IJ AOB_BLOCK included in A0B#7 is the end part of the song 
Q 15 SongD and has a playback period of 5.4 minutes. In this 
J^l way, a song that has a total playback period of 30.6 minutes 
JfJ is divided into (8.4 + 8.4 + 8.4 + 5.4-minute) parts that 
are each included in a different AOB. As can be seen from 
FIG. 16, every song included in an AOB file is subjected 
20 to a maximum playback period of 8.4 minutes. 

This explanation clearly shows that limiting the 
playback periods of AOBs as described above restricts the 
data size of the time search table corresponding to each 
AOB. The following describes the navigation data included 
25 in each time search table. 



43 



{3-3_8A,B-2} 

The navigation data is composed of the two files 
"SD__Audio. PLM" and "SD_Audio . TKM" mentioned earlier. The 
file "SD_Audio . PLM" includes the PlaylistManager, while 
5 the file "SD_Audio .TKM" includes the TrackManager . 

As mentioned as part of the explanation of the 
presentation data, a plurality of AOB files store encoded 
AOBs, though no other information, such as the playback 
period of the AOBs, the names of the songs represented by 

10 theAOBs, or credits for the songwriter (s) , is given. While 
a plurality of AOBs are recorded in a plurality of AOB files, 
no indication as to the playback order of the AOBs is provided. 
To inform a playback apparatus of such information, the 
TrackManager and PlaylistManager are provided. 

15 The TrackManager shows the correspondence between the 

AOBs recorded in AOB files and tracks, and includes a 
plurality of pieces of track management information that 
each give a variety of information, such as the playback 
period of AOBs and the song names and songwriters of the 

20 various AOBs . 

In this specification, the term "track" refers to a 
meaningful playback unit for users, so that when copyrighted 
music is stored on a flash memory card 31, each song is 
a separate track. Conversely, when an "audio book" (i.e., 

25 copyrighted literature stored as recorded audio) is recorded 
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on a flash memory card 31, each chapter or paragraph can 
be set as a separate track. The TrackManager is provided 
to manage a plurality of AOBs recorded in a plurality of 
AOB files as a group of tracks. 

A Playlist sets the playback order of a plurality of 
tracks. A plurality of Playlists can be included in the 
PlaylistManager . 

The following describes the TrackManager with 
reference to the drawings . 

{17-1_18} Detailed Composition 

of the PlaylistManager and TrackManager 

FIG. 17 shows the detailed composition of the 
PlaylistManager and TrackManager in this embodiment as a 
hierarchy. FIG. 18 shows the sizes of the PlaylistManager 
and the TrackManager. The right side of FIG, 17 shows the 
items on the left side in more detail, with the broken lines 
indicating which items are being shown in more detail. 

As shown in FIG. 17, the TrackManager is composed of 
the Track Information (TKI) #1, #2, #3, #4 . . . #n, as 
shown by the broken line hi. These TKIs are information 
for managing the AOBs recorded in AOB files as tracks, and 
each correspond to a different AOB file. From FIG. 17, it 
can be seen that each TKI is composed of 
Track General Information (TKGI) , Track Text Information 
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(TKTXTI_DA) in which text information exclusive to a track 
can be written, and a Track_Time_Search___Table (TKTMSRT) 
that serves as a time search table. 

From FIG. 18, it can be seen that each TKI has a fixed 
5 size of 1,024 bytes, which means that total size of the 
TKGI and the TKTXTI_DA is fixed at 512 bytes due to the 
size of the TKTMSRT being fixed at 512 bytes. In the 
TrackManager, a total of 999 TKIs can be set. 

As shown by the broken line h3, the TKTMSRT is composed 
10 of a TMSRT_Header and TMSRT_entries #1, #2, #3 . . . #n. 

{17-2_19} Correspondence of TKI with AOB files and AOBs 

FIG. 19 shows how the TKIs shown in FIG. 17 correspond 
15 to the AOB files and AOBs shown in FIG. 16. The boxes on 
the first level in FIG. 19 show a sequence of tracks composed 
of tracks TrackA to TrackE, the large frame on the second 
level shows the TrackManager, while the third and fourth 
levels show the eight AOB files given in FIG. 16. The eight 
20 AOB files are recorded in the eight AOBs shown in FIG. 16, 
and compose a music album including tracks TrackA, TrackB, 
TrackC, TrackD, andTrackE. The second level shows the eight 
TKIs. The numbers "1", "2", "3", "4" assigned to each TKI 
are the serial numbers used to identify each TKI, with each 
25 TKI corresponding to the AOB file that has been given the 
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same serial number 001,002,003^004^005 . . • • 

With this in mind, it can be seen from FIG. 19 that 
TKI#1 corresponds to the file "AOBOOl . SAl" , that TKI#2 
corresponds to the file "AOB002 . SAl", TKI#3 corresponds 
5 to the file "AOB003 . SAl", and TKI#4 corresponds to the file 
"AOB004 .SAl" . The correspondence between TKIs and 
AOB__FRAMEs is shown by the arrows TAl, TA2, TA3, TA4 . . . 
in FIG. 19, 

In this way, each TKI corresponds to a different AOB 
10 recorded in an AOB file and gives detailed information that 
applies only to the corresponding AOB. 

{17"3_20} Data Composition of a TKTMSRT 

The following describes the information that applies 
15 to single AOBs recorded in AOB files, starting with the 
TKTMSRT. FIG. 2 0 shows the data composition of the TKTMSRT 
in detail. 

The right side of FIG. 20 shows the detailed data 
composition of the time search table header (TMSRT_Header) . 
20 In FIG. 20, the TMSRT_Header has a data size of eight bytes, 
and is made up of three fields. The first two bytes are 
a TMSRT_ID, the next two bytes are reserved, and the final 
four bytes are a Total TMSRT_entry__Number . 

A unique ID for identifying the TMSRT is recorded in 
25 the "TMSRT ID". The total number of TMSRT entries in the 
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present TMSRT is recorded in the "Total TMSRT__entry Number" . 

{17-3_21-1} Specific Example of the TKTMSRT 

The following describes a TKTMSRT in detail. FIG. 
5 21 shows one example of a TKTMSRT. The left side of FIG. 
21 shows an AOB, while the right side shows the corresponding 
TKTMSRT. The AOB on the left side of FIG. 21 is composed 
of a plurality of AOB__ELEMENTs numbered #1, #2, #3 . . . 
#n that occupy the regions numbered ARl, AR2, AR3 . . . 

10 ARn to the right. 

The numbers such as "0", "32000", "64200", "97000", 
"1203400", and "1240000" show the relative addresses of 
areas ARl, AR2, AR3, ARn-1, ARn occupied by the AOB__ELEMENTs 
with respect to the start of the AOB_BLOCK. As examples, 

15 A0B_ELEMENT#2 is recorded at a position that is at a distance 
"32 000" from the start of the AOB_BLOCK, while A0B_ELEMENT#3 
is recorded at a position that is at a distance "64200" 
from the start of the AOB_BLOCK and AOB_ELEMENT#n-l is 
recorded at a position that is at a distance "1203400" from 

20 the start of the AOB_BLOCK. 

It should be noted that the distance between each 
occupied region and the start of the AOB^BLOCK is not a 
multiple of a certain value, meaning that the regions 
occupied by AOB_ELEMENTs are not of the same size. The reason 

25 the occupied regions have different sizes is that the varying 
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amounts of data are used to encode each AOB_FRAME. 

Since the size of the region occupied by each 
AOB_ELEMENT differs, it is necessary to inform a playback 
apparatus in advance of the position of each AOB__ELEMENT 
5 in an AOB when performing a j ump to the start of an AOB__ELEMENT . 
For this purpose, a plurality of TMSRT__entries are given 
in the TKTMSRT. The arrows RTl, RT2, RT3 . . . RTn-1, 
RTn show the correspondence between the regions ARl, AR2, 
AR3 . . . ARn-1, ARn occupied by each AOB_ELEMENT and 

10 TMSRT_entry#l , TMSRT_entry#2 , TMSRT_entry#3 . . . 

TMSRT_entry#n-l, TMSRT_entry#n . In other words, the size 
of the region ARl occupied by A0B_ELEMENT#1 is written in 
the TMSRT_entry#l, while the sizes of the regions AR2 and 
AR3 occupied by A0B_ELEMENT#2 and A0B_ELEMENT#3 are written 

15 in the TMSRT_entries #2 and #3. 

Since the occupied area ARl takes up the region from 
the start of the AOB to the start of the A0B_ELEMENT#2 "32000", 
the size "32000" (=32000-0) is written in the TMSRT__entry#l . 
The occupied area AR2 takes up the region from the start 

20 of the A0B_ELEMENT#2 "32000" to the start of the 
A0B_ELEMENT#3 "64200", SO that the size "32200" 
(=64200-32000) is written in the TMSRT_entry#2 . The 
occupied area AR3 takes up the region from the start of 
the A0B__ELEMENT#3 "64200" to the start of the A0B_ELEMENT#4 

25 "97000", so that the size "32800" (-97000-64200) is written 
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in the TMSRT_entry#3 . In the same way, the occupied area 
ARn-1 takes up the region from the start of the 
AOB_ELE]y[ENT#n-l "1203400" to the start of the AOB_ELEMENT#n 
"1240000", the size "36600" (=1240000-1203400) is written 
5 in the TMSRT__entry#n-l . 

{17-3_21-2} How the TKTMSRT is read 

In this way, the data sizes of AOB__ELEMENTs are written 
in a time search table. However, since the data length of 

10. each AOB___BLOCK is restricted to a maximum of 8 . 4 minutes, 
the total number of AOB_ELEMENTs included in a single AOB 
is limited to a predetermined number ("252" as shown in 
FIG. 20) or less. Since the number of AOB^ELEMENTs is 
restricted, the number of TMSRT_entries corresponding to 

15 AOB__ELEMENTs is also restricted, which restricts the size 
of the TKTMSRT including these TMSRT_entries to within a 
predetermined size. Since the size of the TKTMSRT is 
restricted, a playback apparatus can read and use TKIs in 
the following way. 

20 The playback apparatus reads a certain AOB and on 

commencing playback of the AOB, reads the corresponding 
TKI and stores it in a memory. This corresponding TKI is 
kept in the memory while the playback of this AOB continues . 
Once the playback of the AOB ends, the following AOB is 

25 read, and when the playback of this AOB commences, the 
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playback apparatus overwrites the TKI corresponding to 
this following AOB into the memory in place of the old TKI. 
This next TKI is kept in the memory while the playback of 
this following AOB continues. 
5 By reading and storing TKIs in this way, the necessary 

capacity of the memory in the playback apparatus can be 
minimized while still enabling special playback functions 
such as forward and backward search to be realized. While 
the present embodiment describes the case where the data 
10 length from the first address of an AOB__ELEMENT to the first 
address of the next AOB__ELEMENT is written in the TMSRT__entry, 
relative addresses from the start of the AOB_BLOCK to the 
first addresses of AOB_ELEMENTs may be written in there 
instead. 

15 

{17-3_21-3} Specifying a Cluster 

Including an AOB_ELEMENT 

The following describes how an AOB_ELEMENT may be read 
using the TKTMSRT, The TKTMSRT includes the size of each 
20 AOB_ELEMENT, SO that when AOB_ELEMENT#y, which is the y^^ 
AOB_ELEMENT from the start of an AOB, is to be read, the 
cluster u that satisfies Equation 1 given below is calculated, 
and data positioned with the offset v from the start of 
the cluster u is read. 

25 
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Equation 1 

Cluster u = (Total of the TMSRT_entries f rom A0B__ELEMENT#1 
to AOB_ELEMENT#y-l + DATA_Offset) / Cluster size 

5 Offset V = (Total of the TMSRT_entries from AOB_ELEiyiENT#l 
to AOB_ELEMENT#y-l + DATA_Offset) mod Cluster size 

where c==a mod b indicates that c is the remainder 
produced when a is divided by b 

10 The DATA_Of f set is written in the BIT and is described 

later in this specification. 

{17-4} TKTXI_DA 

This completes the explanation of the time search table 
15 (TKTMSRT) . The following describes the 

Track_Text___Inf ormation Data Area (TKTXI_DA) recorded in the 
upper part of the TKTMSRT. 

The Track_Text_Inf ormation Data Area (TKTXTI__DA) is 
used to store text information showing the artist name, 
20 album name, mixer, producer, and other such information. 
This area is provided even when such text information does 
not exist. 

{17-5} TK6I 

25 The following describes the TKGI recorded in the upper 
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part of the TKTXI_DA. In FIG. 17, several sets of 
information shown as the identifier "TKI__ID" of the TKI, 
the TKI number "TKIN", the TKI size "TKI_SZ", a link pointer 
to the next TKI "TKI_LNK_PTR" , block attributes 
5 "TKI__BLK__ATR", a playback period "TKI__PB_TM" , the audio 
attributes "TKI_AOB_ATR", an "ISRC", and block information 
"BIT". Note that only some of this information has been 
shown in FIG. 17 to simplify the representation. 

10 {17-5_22-l} TK6I 

The following describes the composition of a TKGI in 
detail, with reference to FIG. 22. The difference between 
FIG. 17 and FIG. 22 is that the data composition of the 
TKGI that was shown in FIG. 17 is arranged on the left side 
15 of this drawing, and that the bit compositions of 

"TKI__BLK__ATR", "TKI_AOB_ATR" and "ISRC" are clearly shown. 

{17-5_22-2} TKI_ID 

A unique ID for a TKI is written in the "TKI_ID" . In 
20 the present embodiment, a two-byte "A4" code is used. 

{17-5_22"3} TKIN 

A TKI number in the range of 1 to 999 is written in 
the "TKIN". Note that the TKIN of each TKI is unique. In 
25 the present embodiment, the position of each TKI in the 
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TrackManager is used as the TKIN. This means that "1" is 
written as the TKI number of TKI#1, "2" is written as the 
TKI number of TKI#2, and "3" is written as the TKI number 
of TKI#3. 

5 

{17-5_22-4} TKI_SZ 

The data size of the TKI in byte units is written in 
the "TKI_SZ". In FIG. 22, 1,024 bytes is given as the data 
size of the TKI so that each TKI in the present embodiment 
10 is 1,024 bytes long, 

{17- 5_2 2 - 5 } TKI_IiNK_PTR 

The TKIN of the TKI to which the present TKI is linked 
is written in the "TKI__LNK__PTR" . The following describes 

15 such links between TKIs. 

When a track is composed of a plurality of AOBs which 
are recorded in a plurality of AOB files, these AOB files 
will be managed as a single track by linking the plurality 
of TKIs that correspond to these AOB files. To link a 

20 plurality of TKIs, it is necessary to show the TKI of the 
AOB file that follows after the AOB file of the present 
TKI. Accordingly, the TKIN of the TKI that follows the 
present TKI is written in TKI LNK PTR. 
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{ 17-5_22 - 6_1 9 } TKI_IiNK_PTR 

The following describes the settings made for the 
TKI_LNK_PTR in the eight TKIs shown in FIG. 19. The track 
information numbered #1 to #3 and #8 each correspond to 
5 separate tracks, so no information is set in their 
TKI_LNK_PTR. The track information 

TKI#4,TKI#5,TKI#6,TKI#7 correspond to the four AOB files 
that compose TrackD, so that the next track information 
is indicated in the TKI_LNK_PTR of these TKIs. As shown 

10 by the arrows TL4, TL5, and TL6 in FIG. 19, "TKI#5" is set 
intheTKI_LNK_PTRof TKI#4, "TKI#6" is set in the TKI__LNK_PTR 
of TKI#5, and "TKI#7" is set in the TKI_LNK_PTR of TKI#6. 

As a result, a playback apparatus can refer to the 
TKI_LNK_PTRs given in the TKIs corresponding to these four 

15 AOB files and so find out that the four TKIs TKI#4 to TKI#7 
and the four AOB files "AOB004.SA1" to "AOB007 .SA1" compose 
a single track, TrackD. 

{17- 5_2 2 " 7 } TKI_BLK_ATR 

20 The attributes of present TKI are written in the 

"TKI_BLK__ATR" . In FIG. 22, the information shown within 
the broken lines extending form the TKI_BLK_ATR shows the 
bit composition of the TKI_BLK_ATR. In FIG. 22, the 
TKI_BLK_ATR is shown as being 16 bits long, with the bits 

25 from b3 to bl5 being reserved for future use. The three 
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bits from bit b2 to bO are used to show the attributes of 
the TKI. 

When one TKI corresponds to a complete track, the value 
"00b" is written in the TKI_BLK_ATR (this setting is 
5 hereafter referred to as "Track") . When several TKIs 
correspond to the same track, the value "001b" is written 
in theTKI_BLK_ATRof the first TKI (this setting is hereafter 
referred to as "Head___of__Track" ) , the value "010b" is written 
in the TKI_BLK_ATRs of the TKIs that correspond to AOBs 
^;|10 in themiddle of the track (this setting is hereafter referred 
JIJ to as "Midpoint_of_Track") , and the value "011b" is written 
Ji: in the TKI_BLK_ATR of the TKI that corresponds to the AOB 
S at the end of the track (this setting is hereafter referred 
to as "End_of__Track") . When a TKI is unused but a TKI region 
015 exists, which is to say, when there is a deleted TKI, the 
Jj value "100b" is written in the TKI_BLK_ATR (this setting 
%l is hereafter referred to as "Unused") . When a TKI is unused 
"^^^ and no TKI region exists, the value "101b" is written in 
the TKI_BLK_ATR. 

20 

{17-5_22"8_19} Example Setting of the TKI_BLK_ATR 

The following describes the settings of the 
TKI_BLK_ATR for each TKI in the example shown in FIG. 19. 
By referring to the TKI_BLK_ATR of each TKI, it can 
25 be seen that the four pairs TKI#1 ("AOBOOl.SAl") , TKI#2 



("AOB002.SA1") , TKI#3 ( "AOB003 . SAl" ) , anclTKI#8 
("AOB008 .SAl") each correspond to separate tracks since 
the TKI_BLK_ATR of each of TKI#1, TKI#2, TKI#3, and TKI#8 
is set as "Track" . 
5 The TLK_BLK_ATR of TKI#4 is set at "Head_of_Track" , 

the TLK_BLK_ATR of TKI#7 is set at "End_of_Track" , and the 
TLK_BLK_ATRof TKI#5 andTKI#6 is set at "Midpoint _of_Track" 
This means that the AOB file ("AOB004 .SAl") corresponding 
to TKI#4 is the start of a track, the AOB files ( "AOB005 . SAl") 

10 and {"AOB006.SA1") corresponding to TKI#5 and TKI#6 are 
midpoints of the track, and the AOB file ( "AOB007 . SAl" ) 
corresponding to TKI#7 is the end of a track. 

By classifying the combinations of TKI and 
corresponding AOB file in accordance with the settings of 

15 theTKI_BLK_ATRintheTKI, it can be seen that the combination 
of TKI#1 and "AOBOOl.SAl" composes a first track (TrackA) . 
Likewise, the combination of TKI#2 and "AOB002 . SAl" composes 
a second track (TrackB) and the combination of TKI#3 and 
"AOB003.SA1" composes a third track (TrackC) . The 

20 combination of TKI#4 and "AOB004.SA1" composes the first 
part of the fourth track (TrackD) , the combinations of TKI#5 
with "AOB005.SA1" and TKI#6 with "AOB006.SA1" compose 
central parts of TrackD, and the combination of TKI#7 and 
"AOB007.SA1" composes the end part of TrackD. Finally, the 

25 combination of TKI#8 and "AOB008 . SAl" composes a fifth track 
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(TrackE) . 



{17- 5_2 2 - 9 } TKI_PB_TM 

The playback period of the track (song) composed of 
the AOB recorded in the AOB file corresponding to a TKI 
is written in the "TKI__PB_TM" in the TKI . 

When a track is composed of a plurality of TKIs, the 
entire playback period of the track is written in the 
TKI_PB_TM of the first TKI corresponding to the track, while 
the playback period of the corresponding AOB is written 
into the second and following TKIs for the track. 

{ 1 7 -5_22 -1 0 } TKI_AOB_ATR 

The encoding conditions used when producing an AOB, 
which is to say information such as (1) the sampling frequency 
at which the AOB recorded in the corresponding AOB file 
was sampled, (2) the transfer bitrate, and (3) the number 
of channels, is written in the "TKI__AOB__ATR" in a TKI. The 
bit composition of the TKI_AOB_ATR is shown within the broken 
lines that extend from the "TKI__AOB__ATR" in FIG. 22. 

In FIG. 22, the TKI_AOB_ATR is composed of 32 bits, 
with the coding mode being written in the four-bit field 
from bit bl6 to bit bl9. When the AOB is encoded according 
toMPEG-2AAC (withADTS header) , the value "0000b" is written 
into this field, while when the AOB is encoded according 
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to MPEG-layer 3 (MP3) , the value "0001b" is written. When 
the AOB is encoded according to Windows Media Audio (WMA) , 
the value "0010b" is written in this field. 

The bitrate used when encoding the AOB is written in 
the eight-bit field between bit bl5 and bit b8 . When the 
AOB is encoded according to MPEG-2 AAC (with ADTS header) ^ 
a value between "16" and "72" is written into this field, 
while when the AOB is encoded according to MPEGl-layer 3 
(MP3) , a value between "16" and "96" is written. When the 
AOB is encoded according to MPEGl-layer 3 (MP3) LSF, a value 
between "16" and "80" is written into this field, while 
when the AOB is encoded according to Windows Media Audio 
(WMA), a value between "8" and "16" is written. 

The sampling frequency used when encoding the AOB is 
written in the four-bit field between bit b7 and bit b4 . 
When the sampling frequency is 48kHz, the value "0000b" 
is written in this field. When the sampling frequency is 
44.1kHz, the value is "0001b", when the sampling frequency 
is 32kHz, the value "0010b", when the sampling frequency 
is 24kHz, the value "0011b", when the sampling frequency 
is 22.05kHz, the value "0100b", and when the sampling 
frequency is 16kHz, the value "0101b". 

The number of channels is written in the three-bit 
field from bit b3 to bit bl. When one channel (i.e., 
monaural) is used, the value "000b" is written in this field. 
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while when two channels (i.e., stereo) is used, the value 
"001b" is written in this field. 

The twelve-bit field from bit b31 to bit 20 is reserved 
for future use, as is the bit bO . 

{17-5_22"11} ISRC 

An ISRC (International Standard Recording Code) is 
written in the TKGI . In FIG. 22, the broken lines extending 
from the "ISRC" box show the content of the ISRC. As shown 
in the drawing, the ISRC is composed of ten bytes, with 
a Recording-item code (#12) being written into the four-bit 
field between bit b4 and bit b7 . A Recording 
code/Recording-item code (#11) is written in the four-bit 
field between bit b8 and bit bll. 

A Recording Code (ISRC#1Q, #9, #8) is written in the 
twelve-bit field between bit bl2 and bit b23. A 
Year-of-Recording code (ISRC#6, #7) is written in the 
eight-bit field b24 and bit b31. 

The First Owner Code (ISRC #3, #4, #5) is written in 
the six-bit field between bit b32 and bit b37, the six-bit 
field between bit b40 and bit b45, and the six-bit field 
between bit b48 and bit b53. The Country Code (ISRC #1, 
#2, #3) is written in the six-bit field between bit b56 
and bit b61 and the six-bit field between bit b64 and bit 
b69. A one-bit Validity flag is written in a one-bit field 
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composed of bit b79. A detailed description of ISRC can 
be found in 1303901:1986 "Documentation-International 
Standard Recording Code (ISRC)". 

5 {17-5_22"12_23A-1} BIT 

The "Block Information Table (BIT) " is a table for 
managing an AOB__BLOCK, and has the detailed composition 
shown in FIGS, 23A and 23B. 

As shown in FIG. 23A, a BIT is composed of a DATA_OFFSET 

10 field that occupies a region from the 60th byte to the 63rd 
byte, an SZ_DATA field that occupies a region from the 64th 
byte to the 67th byte, a TMSRTE_Ns field that occupies a 
region from the 68th byte to the 71st byte, an FNs__lst_TMSRTE 
field that occupies a region from the 72nd byte to the 73rd 

15 byte, an FNs_Last_TMSRTE that occupies a region from the 
74th byte to the 75th byte, an FNs__Middle_TMSRTE field that 
occupies a region from the 7 6th byte to the 77th byte, and 
a TIME_LENGTH field that occupies a region from the 78th 
byte to the 7 9th byte. 

20 Each of these fields is described in detail below. 

{17-5_22-12_23A"2} DATA_Offset 

The relative address of the start of an AOB__BLOCK from 
the boundary between clusters is written in the 
25 "DATA__OFFSET" as a value given in byte units . This expresses 
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the size of an invalid area between an AOB and the AOB_BLOCK. 
As one example^ when a user records a radio broadcast on 
a flash memory card 31 as AOBs and wishes to delete an intro 
part of a track over which a DJ has spoken, the DATA_OFFSET 
in the BIT can be set to have the track played back without 
the part including the DJ's voice. 

{ 1 7 -5_22 " 12_2 3A- 3 } SZ_DATA 

The data length of an AOB_BLOCK expressed in byte units 
is written in "SZ_DATA" . By subtracting a value produced 
by adding the SZ_DATA to the DATA__Of f set from the file size 
(an integer multiple of the cluster size) , the size of the 
invalid area that follows the AOB_BLOCK can be found. 

{ 1 7 -5_22 - 12_23A" 4 } TMSRTE JSIs 

The total number of TMSRT_Entries included in an 
AOB_BLOCK is written in "TMSRTE_Ns", 

{17-5_22-12_23A"5} "FNs_lst_TMSRTE" , 

"FNs_Last_TMSRTE" , "FNs_Middle_TMSRTE" 

The number of AOB_FRAMEs included in the AOB_ELEMENT 
positioned at the start of a present AOB_BLOCK is written 
in "FNs_lst_TMSRTE" . 

The number of AOB_FRAMEs included in the AOB_ELEMENT 
positioned at the end of the present AOB BLOCK is written 
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in "FNs_Last_TMSRTE" , 

The number of AOB_FRAMEs included in each AOB_ELEMENT 
apart from those at the start and the end of the present 
AOB_BLOCK, which is to say AOB_ELEMENTs in the middle of 
the AOB__BLOCK, is written in "FNs_Middle_TMSRTE" . 

The playback period of an AOB_ELEMENT is written in 
the format shown in FIG. 23C in the "TIME_LENGTH" field 
to an accuracy in the order of milliseconds. As shown in 
FIG. 23C, the "TIME_LENGTH" field is 16-bits long. When 
the encoding method used in MPEG-ACC or MPEG-Layer3, the 
playback period of an AOB_ELEMENT is two seconds, so that 
the value "2000" is written in the "TIME_LENGTH" field. 

{17-5_22-13_23B} 

FIG. 2 SB shows the number of AOB_FRAMEs indicated by 
"FNs_Middle_TMRTE" . In the same way as FIG. 14, FIG. 23B 
shows the relationship between the sampling_f requency and 
the number of AOB_FRAMEs included in an AOB_ELEMENT in the 
middle of an AOB_BLOCK. 

The relationship between the sampling_f requency and 
the number of frames included in the AOB_ELEMENT shown in 
FIG. 23B is the same as that shown in FIG. 14, which is 
to say, the number of frames in an AOB_ELEMENT depends on 
the sampling frequency used. The number of frames written 
in "FNs 1st TMSRTE" and "FNs Last TMSRTE" will 
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fundamentally be the same as the number written in 
"FNs__Middle_TMSRTE", though when an invalid area is present 
in the AOB_ELEMENTs at the start and/or end of an AOB_BLOCK, 
the values given in "FNs_lst_TMSRTE" and/or 
5 "FNs_Last__TMSRTE" will differ from the value in 
"FNs_Middle_TMSRTE" . 

{17-5_22-14_24} Example of a Stored AOB_ELEMENT 

FIG. 24 shows the clusters 007 to OOE that store the 

10 AOB composed of A0B_ELEMENT#1 to A0B_ELEMENT#4 . The 

following describes the settings in the BIT when an AOB 
is stored as shown in FIG. 24. A0B_ELEMENT#1 to 
A0B_ELEMENT#4 that are stored in cluster 007 to cluster 
OOE are indicated in FIG. 24 by the triangular flags, with 

15 TMSRT_entries being set in the TKI for each of A0B_ELEMENT#1 
to A0B__ELEMENT#4. 

In this example, the first part of A0B_ELEMENT#1 at 
the start of the AOB is stored in cluster 007, while the 
last part of A0B_ELEMENT#4 at the end of the AOB is stored 

20 in cluster OOE. The AOB_ELEMENTs #1 to #4 occupy the region 
between mdO in cluster 007 to md4 in cluster OOE. As shown 
by arrow sdl in FIG. 24, the SZ_DATA in the BIT indicates 
that AOB__ELEMENTs #1 to #4 occupy a region from the start 
of cluster 007 to the end of cluster OOE, and so does not 

25 indicate that there are the invalid areas udO and udl in 
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clusters 007 and OOE that are not occupied by an AOB__ELEMENT . 

On the other hand, the AOB also includes the parts 
udO and udl that are present in clusters 007 and OOE but 
are not occupied by A0B_ELEMENT#1 or A0B_ELEMENT#4 . The 
5 DATA_Offset given in the BIT gives the length of the 
unoccupied region udO, which is to say, a position value 
for the start of the A0B_ELEMENT#1 relative to the start 
of cluster 007. 

In FIG. 24, the A0B_ELEMENT#1 occupies a region from 

10 mdO in cluster 007 to mdl in cluster 008. 

This A0B_ELEMENT#1 does not occupy all of cluster 008, 
with the remaining part of the cluster being occupied by 
A0B__ELEMENT#2 . A0B_ELEMENT#4 occupies a region from md3 
midway through cluster OOC to md4 midway through cluster 

15 OOE . In this way, AOB_ELEMENTs may be stored across cluster 
boundaries, or in other words, AOB_ELEMENTs can be recorded 
without regard for the boundaries between clusters. The 
"FNs_lst__TMSRTE" in the BIT shows the number of frames in 
A0B___ELEMENT#1 that is located in clusters 007 and 008, while 

20 the "FNs_Last_TMSRTE" in the BIT shows the number of frames 
in A0B_ELEMENT#4 that is located in clusters OOC to OOE. 

In this way, AOB_ELEMENTs can be freely positioned 
without regard for the boundaries between clusters. The 
BIT provides information showing the offset from a cluster 

25 boundary to an AOB___ELEMENT and the number of frames in each 
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AOB__ELEMENT . 

{17-5_22-14_25} Use of the Number of Frames given in each 
AOB_ELEMENT (part 1) 

5 The following describes how the number of frames in 

each AOB_ELEMENT given in the BIT is used. This number of 
frames given in the BIT is used when forward or backward 
search is performed. As mentioned earlier, such operations 
play back 240 milliseconds of data after first skipping 

10 data with a playback period of two seconds. 

FIG. 25 shows howAOB_FRAME#x+l, which should be played 
back next, is set when performing forward search starting 
from an AOB__FRAME#x in an AOB__ELEMENT#y in an AOB. 

FIG. 25 shows the case when a user selects forward 

15 search during the playback of AOB_FRAME#x included in 
AOB_ELEMENT#y . In FIG. 25, "t" represents the intermittent 
playback period (here, 240 milliseconds) , "f (t) " shows the 
number of frames that correspond to this intermittent 
playback period, "skip__time" shows the length of the period 

20 that shouldbe skippedbetween intermittent playback periods 
(here, two seconds), "f (skip__time) " shows the number of 
frames that correspond to this skip time. Intermittent 
playback is achieved by repeating the three procedures (1) , 
(2), and (3) described below. 

25 
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(1) The playback apparatus refers to the TMSRT_entry in 
the TKTMSRT and jumps to the start of the flag symbol 
(AOB__ELEMENT) . 

5 (2) The playback apparatus performs playback for 240 
milliseconds . 

(3) The playback apparatus jumps to the start of the next 
flag symbol (AOB_ELEMENT) , 

10 The AOB_FRAME#x+l that exists 2s+240ms from the 

AOB_FRAME#x included in the AOB_ELEMENT#y will definitely 
be present in the AOB_ELEMENT#y+l . When specifying the 
AOB_FRAME#x+l that is 2s+240ms from the AOB^FRAMEtx, the 
first address of the next AOB_ELEMENT#y+l can be immediately 

15 calculated by reading a TMSRT_ent ry from the TKTMSRT ^ though 
a playback apparatus cannot know the number of AOB_FRAMEs 
from the start address of the AOB__ELEMENT#y+l to the 
AOB_FRAME#x+l from the TMSRT_entry alone. 

To calculate this number of AOB_FRAMEs^ it is necessary 

20 to subtract the total number of frames included in the 
AOB__ELEMENT#y from the total of (1) the number#x showing 
the position of the AOB_FRAME#x relative to the start of 
the AOB__ELEMENT#y, (2) f(t) and (3) f (skip_time) . To 
simplify the calculation of the relative frame position 

25 ofAOB FRAME #x+l in AOB_ELEMENT#y+l, the "FNs_lst_TMSRTE" , 
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"FNs_Middle_TMSRTE", and "FNs__Last___TMSRTE" for each 
AOB__ELEMENT are written in the BIT, as mentioned above. 

{17"5_22-15_26A} Use of the Number of Frames given in each 
5 AOB_ELEMENT (part 2) 

The number of frames written in the BIT is also used 
when the playback apparatus performs a time search function 
where playback starts at a point indicated using a time 
code. In FIG. 2 6A, shows how a playback apparatus can 

10 specify the AOB___ELEMENT and AOB^FRAME corresponding to the 
playback start time indicated by the user. When playback 
is to commence f roma time indicatedby the user, the indicated 
time (in seconds) is set in the Jmp_Entry f ield, andplayback 
should begin from an AOB_ELEMENT#y and an AOB_FRAME position 

15 X that satisfy Equation 2 given below. 

Equation 2 

Jmp__Entry (sec) (FNs_lst_TMSRTE + FNs__middle_TMSRTE*y+ 
x) *20msec 

20 

Since the "FNs___lst_TMSRTE" and "FNs_Middle_TMSRTE" 
are provided in the BIT, these can be substituted into 
Equation 2 to calculate the AOB_ELEMENT#y and AOB_FRAME#x. 
Having done this, a playback apparatus can refer to the 
25 TKTMSRT of the AOB, calculate the first address of the 
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A0B_ELEMENT#y-f-2 (which is the (y+2)^^ AOB_ELEMENT in this 
AOS) , and start the search for AOB_FRAME#x from this first 
address. On finding the x^^ AOB_FRAME, the playback 
apparatus starts the playback from this frame . In this way^ 
5 the playback apparatus can start the playback of data from 
the time indicated by Jmp_Entry (in seconds) . 

In this way, a playback apparatus does not have to 
search for the ADTS header parts of AOB_FRAMEs, and only 
needs to perform the search in AOB_ELEMENTs that are given 

10 in the TMSRT__entries in the TKTMSRT. This means that the 
playback apparatus can find a playback position 
corresponding to an indicated playback time at high speed • 
In the same way, when the Jmp_Entry is set and the 
time search function is used on a track that is composed 

15 of a plurality of AOBs, the playback apparatus only needs 
to calculate an AOB__ELEMENT#y and AOB_FRAME#x that satisfy 
Equation 3 below. 

Equation 3 

20 Jmp_Entry (in seconds) = 

Playback period from A0B#1 to AOB#n -f 
(FNs__lst_TMSRTE (#n+l) +FNs_middle_TMSRTE (#n+l) *y+x) *20m 
sec 

The total playback period of the AOBs from A0B#1 to 
25 AOB#n is as follows . 
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Total Playback Period from A0B#1 to AOB#n = 

["FNs_lst_TMSRTE" (#1) +"FNs_Middle_TMSRTE" (#1) * (Nu 
mber of TMSRT_entries (#1) -2 ) + "FNs_Last_TMSRTE" (#1) + 
5 "FNs_lst_TMSRTE" (#2 ) + ( "FNs_Middle_TMSRTE" (#2) * Number 
of TMSRT_entries (#2)-2) + "FNs_Last_TMSRTE" (#2) + 
"FNs_lst_TMSRTE" (#3) + ( "FNs_Middle_TMSRTE" (#3 )* Number 
of TMSRT_entries (#3) -2) +"FNs_Last_TMSRTE" (#3) . . . 
+ "FNs_lst_TMSRTE" (#n) + ( "FNs_Middle_TMSRTE" (#n) * 
10 Number of TMSRT_entries (#n)-2) + "FNs_Last_TMSRTE" (#n) ] 

*20msec 

Having calculated an AOB#n, an AOB_ELEMENT#y, and 
AOB_FRAME#x that satisfy Equation 3, the playback apparatus 
refers to the TKTMSRT corresponding to the AOB#n+l, searches 
15 for the x''*' AOB_FRAME from the address at which the (y+2)'"' 
AOB_ELE]y[ENT (i.e., A0B_ELEMENT#y+2 ) is positioned, and 
starts the playback from this x^*^ AOB_FRAME. 

{17-5_22-16_27A,B} Deletion of an AOB File and a TKI 

20 This completes the explanation of all of the 

information included in the TKI. The following describes 
how the TKI is updated in the following four cases . In the 
first case (easel) , a track is deleted. In the second case 
(case2) a track is deleted and a new track is recorded. 

25 In the third case (case3) two out of a plurality of tracks 
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are selected and combined into a single track. Finally, 
in the fourth case (case4) , one track is divided to produce 
two tracks . 

The following describes easel where a track is deleted . 
5 FIGS . 27A and 27B show the partial deletion of a track . 

The example in FIGS. 27A and 27B corresponds to the 
TrackManager shown in FIG, 19, and assumes that the user 
has indicated the partial deletion of Track B. The AOB 
corresponding to TrackB is recorded in "AOB002 . SAl", which 

10 is associated with TKI#2. This means that the deletion of 
"AOB002.SA1" is accompanied by the setting of "Unused" into 
the TKI_BLK__ATR of TKI#2. This state where "AOB002.SA1" 
has been deleted and "Unused" has been set into the 
TKI_BLK_ATR Of TKI#2 is shown in FIG, 27B. Since 

15 "AOB002 . SAl" has been deleted, the region that was formerly 
occupied by "AOB002 . SAl" is freed to become an unused region . 
As mentioned above, the other change is that "Unused" is 
set in the TKI_BLK_ATR of TKI#2 . 

20 {17-5__22"17_28A,B} Assignment of TKIs when a new AOB is 
recorded 

The following describes case2 where a new track is 
recorded after the deletion of a track. 

FIG. 28A shows the TrackManager after the deletion 
25 of tracks has been performed several times. As shown in 
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FIG. 28A, if the tracks corresponding to TKI#2, TKI#4, TKI#7, 
and TKI#8 have been deleted^ then "Unused" is set in the 
TKI__BLK_ATR of these TKI • While AOB files are deleted in 
the same way as conventional data files, the TrackManager 
5 is updated by merely setting "Unused" in the TKI_BLK_ATR 
of the corresponding TKI , These means that TKIs whose 
TKI_BLK__ATRs are set at "Unused" can appear at different 
places in the TrackManager, 

FIG- 28B shows how a new TKI and AOB file are written 

10 when a TKI whose TKI_BLK_ATR is "Unused" is present in the 
TrackManager. Like in FIG. 28A, the TKI#2, TKI#4, TKI#5, 
TKI#7, and TKI#8 in FIG. 28B are set as "Unused". 

In FIG. 28B, the new track to be written is composed 
of four AOBs . The unused TKIs used to record these AOBs 

15 are determined according to the DPL_TK_SRPs or can be freely 
chosen. In the present example, the unused TKIs numbered 
TKI#2, TKI#4, TKI#7, and TKI#8 are used to record the TKIs 
for the new track. 

Since these four AOBs compose one track, 

20 "Head_of_Track" is set in the TKI_BLK_ATR of TKI#2, 

"Middle_of_Track" is set in the TKI_BLK_ATR of TKI#4 and 
TKI#7 , and "End_of_Track" is set in the TKI_BLK_ATR of TKI#8 . 
The TKI_LNK__PTR in each of the four TKIs, TKI#2, TKI#4, 
TKI#7, and TKI#8, used to compose the new TrackD is set 

25 so as to show the TKI forming the next part of TrackD, so 
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that as shown by the arrows TL2, TL4, and TL7, TKI#4 is 
set in the TKI_LNK_PTR of TKI#2, TKI#7 is set in the 
TKI_LNK_PTR of TKI#4, and TKI#8 is set in the TKI_LNK_PTR 
of TKI#7. 

5 After this, the files "AOB002 . SAl" , "AOB004 . SAl" , 

"AOB007 .SAl", and "AOB008.SA1" having the same numbers as 
TKI#2,TKI#4,TKI#7,TKI#8 are produced, and the four AOBs 
composing TrackD are stored in these four files. 

By appropriately setting the TKI_LNK_PTRs and 
10 TKI_BLK_ATRs, this fourth track TrackD can be managed using 
TKI#2, TKI#4, TKI#7, and TKI#8. 

As described above, when a new track is written onto 
the flash memory card 31, TKIs in the TrackManager that 
are set as "Unused" are assigned as the TKIs to be used 
15 for tracks that are to be newly recorded. 

{17-5_22-18_2 9A,B} Setting of TKI when Combining Two 
Tracks 

The following describes the updating of the TKI when 
20 combining tracks (case3) - 

FIGS. 29A and 29B show how the TKIs are set when two 
tracks are combined to produce a new track. The example 
in FIG. 29A uses the same TrackManager as FIG. 19 and shows 
the case when the user performs an editing operation to 
25 combine TrackC and TrackE into a single track. 
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In this case^ the AOBs that correspond to TrackC and 
TrackE are recorded in the AOB files "AOB003.SA1" and 
"AOB008.SA1" which correspond to TKI#3 and TKI#8, so that 
the TKI_BLK_ATRs of TKI#3 and TKI#8 are rewritten. FIG. 
5 2 9B shows the TKI_BLK_ATR of these TKIs after rewriting. 
In FIG. 2 9A, the TKI_BLK_ATRs of TKI#3 and TKI#8 is written 
as "Track", but in FIG. 2 9B the TKI_BLK__ATR of TKI#3 is 
rewritten to "Head__of_Track" and the TKI_BLK_ATR of TKI#8 
is rewritten as "End_of_Track" . By rewriting the 

10 TKI_BLK_ATRs in this way, the AOB files "AOB003.SA1" and 
"AOB008.SA1" which correspond to TKI#3 and TKI#8 end up 
being treated as parts of a single track, the new TrackC. 
This operation is accompanied by the TKI__LNK__PTR of TKI#3 
being rewritten to indicate TKI#8. 

15 It should be particularly noted here that while the 

TKI__BLK_ATRs in the TKI are rewritten, no processing is 
performed to physically combine the AOB files "AOB003.SA1" 
and "AOB008 . SAl" . This is because AOB files are each 
encrypted using different FileKeys, so that when combining 

20 AOB files, it would be necessary to perform two processes 
for each AOB file to first decrypt the encrypted AOB file 
and then to re-encrypt the result, resulting in an excessive 
processing load. Also, an AOB file combined in this way 
would be encrypted using a single FileKey, which would make 

25 the combined track less secure that the tracks used to produce 



74 



it. 

The TKI is originally designed so as to suppress the 
size of the TKTMSRT, so that the physical combining of AOB 
files by an editing operation would also carry the risk 
5 of the TKI becoming too large. 

For the reasons given above, editing operations that 
combine tracks leave the AOB files in their encrypted state 
and are achieved by merely changing the attributes given 
by the TKI__BLK___ATRs . 

{17-5_22-18_29A,B-l_30 , 31} Conditions That Should be 
III Satisfied When Combining Tracks 

The combining of tracks is performed by changing the 
JiJ TKI_BLK_ATR attributes as described above, but the AOBs 
%a5 that are included in the combined tracks should satisfy 
Jj5 the conditions given below. 

ill A first condition is that the AOB that is to compose 

Q a latter part of a new track needs to have the same audio 
attributes (audio coding mode, bitrate, sampling frequency, 
20 number of channels, etc.) as the AOB that is to compose 
the first part of the new track. If an AOB has different 
audio attributes to the preceding or succeeding AOB, the 
playback apparatus will have to reset the operation of the 
decoder, which makes seamless (i.e., uninterrupted) 
25 playback of consecutive AOBs difficult. 
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The second condition is that in the track produced 
by the combining, three or more AOBs made up of only 
AOB_ELEMENTs whose number of AOB__FRAMEs is below the 
required number for an "FNs__Middle_TMSRTE" cannot be linked. 

5 AOBs are classified into two types depending on whether 

at least one AOB_ELEMENT includes a same number of AOB_FRAMEs 
as the number of frames stipulated for an 
"FNs_Middle_TMSRTE" . The Typel AOB includes at least one 
AOB_ELEMENT having this number of AOB_FRAMEs, while the 

10 Type2 AOB includes no AOB_ELEMENT having this number of 
AOB_FRAMEs . 

In other words, AOB__ELEMENTs in a Type2 AOB have fewer 
AOB_FRAMEs than "FNs_Middle_TMSRTE" , and the second 
condition stipulates that three Type2 AOBs cannot be linked 
15 together. 

The reason for the second condition is as follows. 
When the playback apparatus reads AOBs successively, it 
is preferable for a sufficient number of AOB_FRAMEs to 
accumulate in the buffer of the playback apparatus, though 

20 this cannot be achieved when there are consecutive Type2 
AOBs. In such case, an underflow is likely to occur in the 
buffer of the playback apparatus, so that uninterrupted 
playback by the playback apparatus can no longer be 
guaranteed. Therefore, in order to avoid such underflows, 

25 the second condition stipulating that three or more Type2 
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AOBs cannot be linked continuously is used. 

FIG. 30A shows a Typel AOB, while FIG. 30B shows two 
examples of Type2 AOBs. In FIG. 30B, both AOBs are composed 
of less than two AOB_ELEMENTs , with none of the AOB_ELEMENTs 

5 including a number of AOB__FRAMEs that is set for an 

"FNs Middle__TMSRTE" . Since the absence of an AOB_ELEMENT 
with the number of AOB__FRAMEs set for an "FNs_Middle_TMSRTE" 
is the condition by which an AOB is classified as a Type2 
AOB, this means that all of the AOBs shown in this drawing 

10 are classified as Type2 AOBs. 

In FIG. 31A, a combining of Typel+Type2+Type2+Typel 
AOBs into a single track is shown. As this combining does 
not involve the linking of three Type2 AOBs, these AOBs 
may be linked to form a single track. 

15 FIG. 31B shows the linking of Typel+Type2+Type2+ 

Type2+Typel AOBs into a single track. This combining would 
result in there being three consecutive Type2 AOBs, and 
so is prohibited. 

20 

{17-5_22-18_29A,B"l_32} Combining of Tracks with respect 
to conibinations of Typel and Type2 AOBS 

In the combining of AOBs into a single track shown 
in FIG. 31A, if the last AOB in the first track is a Typel 
25 AOB, the combining can be performed regardless of whether 
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the first part of this track is a Typel AOB or a Type2 AOB. 
FIG, 32A shows the case where the last AOB in the first 
track is a Typel AOB and the first AOB in the next track 
is also a Typel AOB. FIG. 32B shows the case where the last 
5 AOB in the first track is a Typel AOB and the first AOB 
in the next track is a Type2 AOB. As the second condition 
is satisfied in both of these cases, the illustrated tracks 
can be combined into a single track. 

When the last AOB in the first track is a Type2 AOB 

10 and the preceding AOB in the first track is a Type 1 AOB, 
this first track can be combined with a following track 
that starts with a Typel AOB regardless of whether the first 
AOB in the first track is a Typel AOB or a Type2 AOB. 

FIG. 32C shows the case where the first track ends 

15 with a Typel AOB and a Type2 AOB in that order and the second 
track starts with a Typel AOB . FIG . 32D shows the case where 
the first track ends with a Typel AOB and a Type2 AOB in 
that order and the second track starts with a Type2 AOB 
and a Typel AOB in that order. As the second condition is 

20 satisfied in both of these cases, the illustrated tracks 
can be combined into a single track. 

When the first track ends with a Type2 AOB and the 
immediately preceding AOB is also a Type2 AOB, this first 
track can be combined with a following track that starts 

25 with a Typel AOB. FIG. 32E shows the case where the first 
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track ends with two Type2 AOBs and the second track starts 
with a Typel AOB. As the second condition is satisfied 
in this case, the illustrated tracks can be combined into 
a single track. In this way, when two tracks are to be 
combined, an investigation is performed to see whether the 
two tracks satisfy the first and second conditions and the 
two tracks are only combined if they are judged to satisfy 
these conditions. 

The following describes the updating of the TKI for 
case4 where a track is divided. 

{17"5_22-19_33A,B} Settings for the TKI When a Track is 
Divided 

FIGS. 33A and 33B show examples of when a single track 
is to be divided to produce two new tracks. For these 
examples, the content of the TrackManager is the same as 
in FIG. 27, with the user being assumed to have performed 
an editing operation that divides TrackC into two new tracks , 
TrackC and TrackF. When TrackC is to be divided into a new 
TrackC and TrackF, the AOB file "AOB002.SA1" is generated 
corresponding to TrackF, FIG. 33A shows that TKI#2 is set 
as "Unused", with this TKI#2 being assigned to the newly 
generated AOB f ile . "AOB002 . SAl" . 
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{17"5_22-19_33A^B-1_34A,B} Updating of the Directory 
Entries and the PAT Values 

When the AOB file "AOB003.SA1" is divided to produce 
"AOB002.SA1" the directory entries and FAT values have to 
5 be updated. This updating is explained below. FIG. 34A 
shows how the SD~Audio Directory Entry in the SD-Audio 
Directory to which the AOB file "AOB003.SA1" belongs is 
written before the file is divided. 

The AOB file "AOB003.SA1" is divided into a plurality 
10 of parts that are stored in clusters 007, 008, 009, OOA . . . 
OOD, OOE. In this case, the first cluster number for the 
AOB file "AOB003 . SAl" given in the directory entry is written 
as "007". The values (008), (009), (OOA) . . . (OOD), (OOE) 
are also written in the FAT values 007, 008, 009, OOA . , . 
15 OOD corresponding to the clusters 007, 008, 009, OOA . . . 
OOD. 

When the AOB file "AOB003.SA1" is divided so that its 
latter part becomes the new AOB file "AOB002 . SAl" , a 
"filename", a "filename extension" and a "number of first 

20 clusters in file" for the new AOB file "AOB002.SA1" are 
added to the SD-Audio directory entry. FIG. 34B shows how 
the SD-Audio Directory Entry in the SD-Audio Directory to 
which the AOB file "AOB003.SA1" belongs is written after 
the AOB file "AOB003.SA1" has been divided. 

25 In FIG. 34B, the cluster OOF stores a copy of cluster 
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OOB that includes the boundary indicated by the user when 
dividing the file. The parts of the AOB file "AOB002.SA1" 
that follow the part included in the cluster OOB are stored 
in the clusters OOC, OOD, OOE as before. Since the first 
5 part of the AOB file "AOB002,SA1" is stored in the cluster 
OOF and the remaining parts are stored in the clusters OOC, 
OOD, OOE, "OOF" is written into the "number of first cluster 
in file" for the new AOB file "AOB002 • SAl" , while (OOC) , 
(OOD) , (OOE) are written into the FAT values OOF, OOC, OOD, 
10 OOE corresponding to the clusters OOF, OOC, OOD, and OOE. 

{ 1 7 "5_22 " 1 9_33A , B-2_35A , B } 

Setting of the Information Fields in the TKI 

The following describes how the information fields 
15 in the TKI are set for the AOB file "AOB002.SA1" once this 
file has been obtained by updating the directory entries 
and the FAT values. When generating a TKI for a divided 
track, there are two kinds of information fields in the 
TKI. These are (1) information that can be copied from the 
20 original TKI and (2) information obtained by updating the 
information in the original TKI. The TKTXTI_DA and ISRC 
are the former type, while the BIT, the TKTMSRT and other 
information fields are the latter type. Since both types 
of information exist, the present embodiment generates a 
25 TKI for a divided track by copying the original TKI to produce 
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a template for the new TKI, and then dividing/updating the 
TKTMSRT and BIT in this template and updating the remaining 
information fields. 

FIG. 35A shows the case where an AOB_FRAME in an AOB 
5 is divided. The first level in FIG. 35A shows the four 
AOB_ELEMENTs, A0B_ELEMENT#1 , A0B__ELEMENT#2 , A0B_ELEMENT#3 , 
and A0B_ELEMENT#4 . The data lengths of these AOB_ELEMENTs 
are set in the TKTMSRT as the four TMSRT_entries #1, #2, 
#3, and #4. If the boundary bdl for the division is set 

10 in A0B_ELEMENT#2 in FIG. 35A, A0B_ELEMENT#2 is divided into 
a first region (1) made up of the frames located before 
the boundary bdl and a second region (2) composed of the 
frames located after the boundary bdl. FIG. 35B shows the 
two AOBs A0B#1 and A0B#2 obtained by dividing the AOB midway 

15 though A0B_ELEMENT#2. 

{17"5_22-19_33A,B-3_36} Setting of the BIT 

FIG. 36 shows how the BIT is set when an AOB is divided 
as shown in FIG. 35, The AOB shown in FIG. 35 is divided 

20 at the boundary bdl. The A0B#1 produced by this division 
includes the two AOB_ELEMENTs A0B_ELEMENT#1 and 
A0B_ELEMENT#2, while the other A0B#2 produced by this 
division includes the three AOB_ELEMENTs, A0B_ELEMENT#1^ 
A0B_ELEMENT#2 , and A0B_ELEMENT#3 . 

25 In FIG. 36, these AOB__ELEMENTs have also been given 
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the triangular flags to shows the settings of the 
TMSRT_entries included in the TKIs corresponding to these 
AOBs . The explanation will first focus on A0B#1 which is 
obtainedby this division. A0B_ELEMENT#1 and A0B_ELEMENT#2 
5 that are included in A0B#1 occupy cluster 007 to cluster 
OOA, so that A0B#1 is handled as being the composite of 
cluster 007 to cluster OOA. A0B_ELEMENT#2 in A0B#1 has a 
data length that ends not at the end of cluster OOA, but 
at the boundary bdl that is present within cluster OOA, 

10 so that the SZ_DATA for A0B#1 is given as the amount of 
data from the region mdO to the boundary bdl in cluster 
OOA. The "FNs_lst_TMSRTE" for A0B#1 is the same as before 
division, while the "FNs__Last_TMSRTE" for A0B#1 differs 
from the value used before division in that it now indicates 

15 the number of frames from the start of A0B_ELEMENT#2 before 
division to the boundary bdl. 

The following describes A0B#2 which is obtained by 
this division. A0B_ELEMENT#1, A0B_ELEMENT#2 , and 
A0B_ELEMENT#3 that are included in A0B#2 occupy cluster 

20 OOB to cluster 007. Cluster OOF includes a copy of the 
content of cluster OOA. The reason cluster OOF stores a 
copy of cluster OOA is that cluster OOA is occupied by 
A0B__ELEMENT#2 in A0B#1, so that it is necessary to assign 
a different cluster to A0B_ELEMENT#1 in A0B#2 . 

25 AOB ELEMENT#1 in A0B#2 has a data length that starts 
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not at the beginning of cluster OOF, but at the boundary 
bdl that is present within cluster OOF, so that the SZ__DATA 
for AOB#2 is given as the amount of data from the start 
of cluster OOB to a point midway through cluster OOE plus 
5 the data length of the part of cluster OOF occupied by 
A0B__ELEMENT#1. 

The part of A0B_ELEMENT#2 in A0B#1 that is included 
in the copy of cluster OOA stored in cluster OOF needs to 
be excluded from A0B#2, so that the DATA_Offset field in 

10 the BIT of A0B#2 is set at the size of the part of A0B_ELEMENT#2 
in A0B#1 included in cluster OOF. 

As can be seen from FIG. 36, the division of the AOB 
result in only the AOB__ELEMENT that includes the boundary 
for the division being divided into two and in the other 

15 AOB_ELEMENTs positioned before and after the divided 
AOB_ELEMENT remaining unchanged. As a result, the 
"FN___Last__TMSRTE" of A0B#2 is set at the same value for the 
"A0B_ELEMENT#4" before the division, and the 
"FNs_lst_TMSRTE" of A0B#2 is set at A0B_ELEMENT#1 of A0B#2, 

20 which is to say, the number of frames included in the part 
that follows the boundary once A0B___ELEMENT#2 has been 
divided. 

{17-5_22-19_33A,B-4_37} Setting of the BIT 

25 FIG. 37 shows a more specific example of changes in 
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the BITS as a result of the division of a track. The left 
side of FIG. 37 shows an example of the settings of the 
BIT before division. In this BIT, the Data__Offset is set 
as "X", the SZ_DATA is set at "52428", and the TMSRTE_Ns 
5 is set at "n". The FNs__lst_TMSRTE is set at "80 frames", 
the FNs_Middle_TMSRTE is set at "94 frames", and the 
FNs_Last_TMSRTE is set at "50 frames". 

The right side of FIG. 37 shows the settings of two 
BITS produced by the division of a track. When the AOB 

10 corresponding to the BIT on the left side of FIG. 37 is 
divided as shown in FIG. 35A, the Data_Offset in the BIT 
of the first track produced by the division is set at "X" 
like the track before division", the "SZ_DATA" is updated 
to the data length "Q" from the start to the division point 

15 Q, and the TMSRTE_Ns is set at "k" which shows the number 
of TMSRT_entries from the first TMSRT__entry to the k^^ 
TMSRT__entry . The FNs_lst_TMSRTE and FNs_Middle_TMSRTE are 
respectively set at "80" and "94" frames in the same way 
as the BIT before division, but since the final AOB__ELEiyiENT 

20 in the AOB of the first trackproducedby the division includes 
"p" AOB__FRAMES, the FNs_Last_TMSRTE is set at "p frames." 

In the BIT of the second trackproducedby the division, 
the "Data__Of f set" is set at "R", the "SZ_DATA" is set at 
(original SZ#DATA "52428"~data length up to division point 

25 Q) ,and the TMSRTE_Ns is set at "n-k+1" produced by adding 
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one (for the kth TMSRT__entry that is newly added as a result 
of the division) to the number of TMSRT_entries from the 
k^^ TMSRT_entry to the n^^ TMSRT_entry. 

The FNs_Middle_TMSRTE and FNs_Last__TMSRTE are set at 
5 the same values as the BIT before division, which is to 
say, "94 frames" and "50 frames" respectively. 

The first AOB__ELEMENT in the AOB of this second track 
includes "94-p" AOB_FRAMEs, so that "94-p" is set in the 
FNs_lst_TMSRTE of the BIT corresponding to this track. 

10 

{17-5_22"19_33A,B"5_38} Setting of the BIT 

FIG. 38 shows . the TKTMSRT after division. The 
following explains the settings of the TMSRT first. The 
TMSRT of the first track includes the TMSRT_entries from 
15 the first TMSRT__entry of the AOB before division to the 
kth TMSRT__entry, which is to say, the TMSRT__entries #1 to 
#k. 

It should be noted here that the AOB_ELEMENT#k that 
includes the boundary for the division only includes region 

20 (1) , so that the k^^ TMSRT_entry only includes a data size 
corresponding to this region (1) . The TMSRT of the second 
track includes the TMSRT___entries from the kth TMSRT_entry 
of the AOB before division to the n^^ TMSRT_entry, which 
is to say, the TMSRT_entries #k to #n. It should be noted 

25 here that the AOB ELEMENT#k that includes the boundary for 
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the division only includes region (2) , so that the k 
TMSRT_entry only includes a data size corresponding to this 
region (2) . 

The copying of the TKI is accompanied by the division 
5 and updating of the TKTMSRT and the BIT ^ and once the remaining 
information has been updated, the TKIs for the new tracks 
produced by the division will be complete. In the same way 
as when combining tracks, the AOB files are not decrypted, 
so that two tracks can be produced by dividing an AOB file 

10 in its encrypted state. Since the division of an AOB file 
does not involve decryption and re-encryption, the 
processing load of dividing a track can be suppressed. This 
means that tracks can be edited even by a playback apparatus 
with limited processing power. 

15 This completes the explanation of the TKI. The 

following describes the Playlists. 

{17-6} Playli s tManager 

As shown by the broken lines h5 in FIG. 17, the 

20 PlaylistManager shown is made up of 

PlaylistManager_Inf ormation (PLMGI) for managing the 
Playlists stored in the flash memory card 31, 
Default_Playlist_Inf ormation (DPLI) for managing all of 
the track stored in the flash memory card 31, and 

25 Playlistlnformation (PLI) #1, #2, #3, #4 . . . #m. Each 
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PLI is information for a user-defined Playlist. As shown 
by the broken lines h6, the DPLI is composed of 
Default_Playlist_General_Information (DPLGI) and 
Default_Playlist_Track__Search_Pointers {DPL_TK_SRP) #1, 
5 #2, #3;. #4 • . . #m. As shown by the broken lines Yil , each 
PLI is composed of Playlist_General_Inf ormation (PLGI) , 
andPlaylist_Track_Search__Pointers (PL_TK_SRP) #1, #2, #3, 
#4 . . . #m. 

The DPLI referred to here differs from each PLI in 
10 the following way. While the DPLI has to indicate all of 
the tracks stored in the flash memory card 52, a PLI does 
not have this restriction and can indicate any number of 
the tracks • This opens up various possibilities for the 
user. As representative examples, the user can generate 
15 Playlist_Information indicating only his (her) favorite 
tracks and store this Playlist_Inf ormation in the flash 
memory card 31, or can have a playback apparatus 
automatically generate Playlist__Inf ormation that only 
indicates tracks of a certain genre, out of a plurality 
20 of tracks stored in the flash memory card 31, and store 
the resulting Playlist Information in the flash memory card 
31. 

{17-7 18} Nuiober of Playlists and Their Data Sizes 

25 As shown in FIG. 18, a maximum of 99 Playlists can 
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be stored on one flash memory card 31. The combined data 
size of the PlaylistManager_Inf ormation (PLMGI) and the 
Default Playlist Information (DPLI) is also fixed at 2,560 
bytes. Each PLI has a fixed length of 512 bytes. The 
5 "DPL_TK_SRP" included in the Default Playlist Information 
includes a "DPL_TK__ATR" and a "DPL_TKIN" . On the other hand, 
the "PL_TK_SRP" field included in a PLI includes only a 
"PL_TK_SRP". The format of the DPL_TK_ATR, DPL_TKIN, and 
PL_TKIN fields is shown in FIG^ 39. 

10 

{17-8_39-l} Format of DPL_TK_SRP 

FIG. 39A shows the format of the DPL_TK_SRP. In FIG. 
39A, the DPL_TKIN is written in the 0th to 9th bits in the 
DPL_TK__SRP, while the DPL_TK__ATR is written in the 13th 
15 to 15th bits. The 10th to 12th bits in the DPL__TK__SRP are 
reserved for future use. 

The TKI number is written in the DPL_TKIN that occupies 
the 0th to 9th bits in the DPL_TK_SRP. This enables a TKI 
to be specified. 

20 

{17-9_39B} Format of the PL_TK_SRP 

FIG. 39B shows the format of the PL_TK_SRP. This is 
a ten-bit field in which PL_TKIN, which is to say, a TKI 
number, is written. 

25 
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{17-8_39A-2} Composition of DPL_TK_ATR 

The broken lines h51 and h52 that extend from the 
DPL_TK_ATR in FIG. 39A show an example setting of the 
DPL_TK__ATR. As can be seen from this drawing, the DPL__TK_ATR 
5 is set for a DPL_TK_SRP in the same way as TKI_BLK_ATR is 
set for a TKI, which is to say, the DPL_TK_ATR is set at 
one of "Track", "Head_of__Track" 
"Midpoint_of_Track", and "End_of_Track" . 

In more detail, when the TKI indicated by the TKIN 

10 is used and an Audio Object (AOB) corresponding to one 
complete track is recorded in the AOB file corresponding 
to the indicated TKI (i.e., when the TKI__BLK_ATR of the 
TKI is "Track") , the value "00b" is set in the "DPL_TK_ATR" . 
When the TKI indicated by the TKIN is used and an Audio 

15 Object (AOB) corresponding to only the start of a track 
is recorded in the AOB file corresponding to the indicated 
TKI (i.e., when the TKI_BLK_ATR of the TKI is 
"Head_of_Track") , the value "001b" is set in the 
"DPL__TK_ATR". When the TKI indicated by the TKIN is used 

20 and an Audio Object (AOB) corresponding to a midway part 
track is recorded in the AOB file corresponding to the 
indicated TKI (i.e., when the TKI__BLK_ATR of the TKI is 
"Midpoint__of_Track") , the value "010b" is set in the 
"DPL__TK_ATR" . When the TKI indicated by the TKIN is used 

25 and an Audio Object (AOB) corresponding to an end part of 
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a track is recorded in the AOB file corresponding to the 
indicated TKI (i.e., when the TKI_BLK_ATR of the TKI is 
"End_of_Track") , the value "011b" is set in the 
"DPL__TK_ATR" . 

5 Conversely, when the TKI indicatedby the TKIN is unused 

and the TKI region is merely established, which corresponds 
to when a TKI has been deleted (i,e., when the TKI_BLK_ATR 
of the TKI is "Unused"), the value "100b" is set in the 
DPL_TK_ATR. 

10 When the TKI indicated by the TKIN is unused and no 

TKI region has been established, which is to say, when a 
TKI is in an initial state, the value "101b" is set in the 
"DPL_TK_ATR". 

Since the number of a TKI is written in the DPL_TKIN, 

15 it is clear which of the plurality of TKI corresponds to 
each DPL_TK_SRP. The position of the DPL_TK_SRP in the 
Def ault_Playlist_Inf ormation shows when the AOB 
corresponding to the TKI that in turn corresponds to the 
DPL_TK_SRP will be played back, i.e. , the ordinal position 

20 of the AOB in the Def ault_Playlist . As a result, the order 
of the DPL__TK_SRP items in the Def ault_Playlist denotes 
the order in which a plurality of tracks will be played, 
or in other words, determines the playback order of tracks. 

25 
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{17-9__40-l} Interrelationship Between the 
Default_Playlist_Information, TKI, and AOB files 

FIG. 40 shows the interrelationship between the 
Default_Playlist_Information, the TKI, and the AOB files. 
5 The second, third, and fourth levels in this drawing are 
the same as the first, second, and third levels in FIG. 
19, and so show a TrackManager including eight TKI and eight 
AOB files. FIG. 40 differs from FIG. 19 in that a box showing 
the Def ault_Playlist_Inf ormation is given on the first level . 

10 The eight small divisions shown in this box show the eight 
DPL_TK_SRP included in the Def ault_Playlist__Inf ormation . 
The upper part of each division shows the DPL_TK_ATR, while 
the lower part shows the DPL__TKIN. 

As shown by the arrows DTI, DT2, DT3, DT4 ... in 

15 FIG. 40, DPL_TK_SRP#1 and TKI#1 are related, as are 
DPL_TK_SRP#2 and TKI#2, DPL_TK_SRP#3 and TKI#3, and 
DPL_TK_SRP#4 and TKI#4. 

Looking at the DPL__TK_ATR fields in the DPL__TK_SRP, 
it can be seen that "Track" has been set for each of 

20 DPL__TK_SRP#1, DPL__TK_SRP#2 , DPL_TK_SRP#3 , and 

DPL_TK_SRP#8 . In other words, the four combinations 
DPL__TK_SRP#1 TKI#1 ("AOBOOl.SAl") , DPL__TK_SRP#2 
TKI#2 ("AOB002.SA1") , DPL__TK__SRP#3 TKI#3 ( "AOB003 . SAl") , 
DPL_TK_SRP#8 TKI#8 ("AOB008 .SAl") correspond to four 

25 separate tracks. 
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Meanwhile, none of DPL_TK_SRP#4 , DPL_TK_SRP#5, 
DPL_TK_SRP#6, and DPL_TK_SRP#7 has a DPL_TK_ATR set as 
"Track". Instead, the DPL_TK_SRP#4 of DPL_TK_ATR is set 
at "Head_of_Track", the DPL_TK_ATR of DPL_TK_SRP#7 is set 
5 at "End_of_Track" and the DPL_TK_ATRs of DPL_TK_SRP#5 and 
DPL_TK_SRP#6 are set at "Midpoint_of_Track" . 

This means that TKI#4 ( "AOB004 . SAl" ) , which is related 
to DPL_TK_SRP#4, is the start of a track, 
TKI#5("AOB005.SA1") and TKI#6 ( "AOB00 6 . SAl") , which are 

10 respectively related to DPL_TK_SRP#5 and DPL_TK_SRP# 6, are 
middle parts of a track, and TKI#7 ("AOB007 .SAl") , which 
is related to DPL_TK_SRP#7, is the end of a track. 

The DPL_TK_SRP entries in the Def aultPlaylist show in 
what order the AOBs corresponding to each TKI are to be 

15 playedback. The DPL_TKINs of DPL_TK_SRP#1, #2, #3, #4 . . . 
#8 in the Def aultPlaylist of FIG. 40 indicate TKI#1, #2, 
#3, #4 . . . #8. As shown by the arrows (1) (2) (3) (4) . . . 
(8) , the AOB file "AOBOOl.SAl" corresponding to TKI#1 will 
be played back first, "AOB002.SA1" corresponding to TKI#2 

20 will be played back second, "AOB003.SA1" corresponding to 
TKI#3 will be played back third, and "AOB004.SA1" 
corresponding to TKI#4 will be played back fourth. 

25 



93 



{17"10_41} Example Settings for the Def aultPlaylist and 
Playli s t_Inf onna tion 

FIG. 41 shows example settings for the 
Default_Playlist and the Playlist_Inf ormation using the 
5 same notation as FIG, 40. In FIG. 41, the box on the first 
level shows the Def ault__Playlist, while the three boxes 
on the second level show the PLIs. 

The small divisions in the box showing the 
Def ault_Playlist shows the eight DPL_TK_SRP values included 
10 in the Def ault_Playlist, while the small divisions in the 
boxes illustrating each PLI show three or four PL_TK_SRP 
values . The setting of the TKIN of each DPL__TK__SRP included 
in the Def ault_Playlist_Inf ormation is the same as in FIG. 
40. However, the settings of the TKIN of the PL__TK_SRP 
15 included in each PLI are completely different to those in 
the DPL_TK_SRP. 

{17-10_42} Correspondence between the DPL_TK_SRP and the 
TKI 

20 FIG. 42 shows the correspondence between the 

DPL_TK_SRP and the TKI using the same notation as in FIG. 
40. In FIG. 42, Playlist#l is composed of PL_TK_SRP#1, #2, 
#3. Of these, #3 is written as the PL_TKIN of PL_TK_SRP#1, 
while #1 is written as the PL_TKIN of PL_TK_SRP#2 and #2 

25 as the PL TKIN of PL TK SRP#3. This means that when tracks 
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are played back according to Playlist#l, a plurality of 
AOBs will be played back as shown by the arrows (11) (12) 
(13) in the order A0B#3, A0B#1, A0B#2, 

Playlist#2 is composed of PL_TK_SRP#1, #2, #3. Of 
5 these, #8 is written as the PL_TKIN of PL_TK_SRP#1, while 
#3 is written as the PL_TKIN of PL_TK_SRP#2 and #1 as the 
PL__TKIN of PL__TK__SRP#3 . This means that when tracks are 
played back according to Playlist#2, a plurality of AOBs 
will be played back, as shown by the arrows (21) (22) (23) 

10 in the order A0B#8, A0B#3, A0B#1, which is to say, in a 
completely different order to Playlist#l. 

Playlist#3 is composed of PL_TK__SRP#1, #2, #3, #4. the 
PL__TKIN of these PL_TK__SRP#1 to #4 are respectively set 
as #8, #4, #3, and#l. This means that when tracks are played 

15 back according to Playlist#3, a plurality of AOBs will be 
played back as follows. First, A0B#8 that composes TrackE 
is played back as shown by the arrow (31) • Next, A0B#4, 
A0B#5, A0B#6, and A0B#7 that compose TrackD are played back 
as shown by the arrow (32) . After this, A0B#3 and A0B#1 

20 that respectively compose TrackC and TrackA are played back 
as shown by the arrows (33) and (34) . 

Of special note here is that when a track is composed 
of a plurality of TKl, only the TKI number of the start 
of the track is written into the PL_TK__SRP entry. In more 

25 detail, while the DPL_TK_SRP values given in the 
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Def ault__Playlist__Inf ormation specifies the four TKIs 
(TKI#4,TKI#5,TKI#6,TKI#7) that compose TrackD, the 
PL_TK__SRP given in a set of Playlist_Inf ormation does not 
need to indicate all four TKIs. For this reason, 
5 PL_TK_SRP#2 in Playlist#3 only indicates TKI#4 out of TKI#4 
to TKI#7. 

On the other hand, a DPLI including a plurality of 
DK_TK__SRP has a data size that is no greater than one sector 
and is always loaded into the RAM of a playback apparatus. 

10 When tracks are played back according to a Playlist, the 
playback apparatus refers to the DK_TK_SRPs that are loaded 
into its RAM and so can search for TKIs at high speed. To 
play back TKIs (AOBs) using a PL__TK_SRP that only indicates 
the TKI number of the first TKI, a playback apparatus searches 

15 the DPL_TK_SRP loaded in its RAM based on the TKI indicated 
by the PL_TK__SRP and judges whether the current track is 
composed of a plurality of TKI. If so, the playback 
apparatus executes the appropriate procedure for playing 
back all of the corresponding TKIs (AOBs) . 

20 As described above, the Def ault__Playlist and a 

plurality of PLIs are written in the Playlist_Manager . If 
different playback orders are written in the DPL_TKINs and 
PL_TKINs of the DPL_TK_SRPs and PL_TK_SRPs composing such 
playlists, it becomes possible to play back AOBs in different 

25 orders. By offering a variety of playback orders to the 
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user in this way, the user can be given the impression of 
there being a number of music albums stored in the flash 
memory card 31. 

Of special note here is that the data size of the 
5 DPL_TK_SRP corresponding to an AOB file is small (at no 
more than two bytes) , while the data size of the TKI 
corresponding to an AOB file is large (at up to 1, 024 bytes) • 
When reordering the TKI in the TrackManager, a large number 
of accesses need to be made to the flash memory card 31, 

10 but when the DPL__TK_SRPs are reordered in the 

Def ault__Playlis t__Inf ormation or a PLI , this can be performed 
with fewer accesses to the flash memory card 31. 

In view of this, when the navigation data is edited, 
the order of the DPL_TK__SRPs in the Def ault_Playlist is 

15 actively changed in accordance with the editing operation, 
while the order of the TKI in the TrackManager is left 
unchanged in spite of the editing operation. 

{17"9_40-2_43A,B} Reordering of the DPL_TK_SRP 

20 The following describes an editing operation that 

changes the playback order of tracks by reordering the 
DPL_TK__SRPs in the Def ault_Playlist_Inf ormation . FIGS. 
43A and 43B show one example of the reordering of tracks. 
The settings of the DPL_TK_SRPs and TKIs in FIG. 4 3A are 

25 the same as in FIG. 40. 
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In FIG. 4 OA, the DPL_TKIN in DPL_TK_SRP#3 is set at 
TKI#3, while the DPL_TKIN in DPL_TK__SRP#8 is set at TKI#8. 
The following describes the case when these DPL_TK_SRPs 
with the thick outlines in FIG. 40A are interchanged. 
5 The numbers (1) (2) (3) (4) (5) (6) (7) (8) in FIG. 43B show 

the playback order of tracks after this editing operation. 
It should be noted here that while the playback order shown 
in FIG. 43A is TrackA, TrackB, TrackC, TrackD, TrackE, in 
FIG. 43B the DPL_TKINs of DPL_TK__SRP#3 and DPL_TK_SRP#8 

10 are interchanged in the Def ault_Playlist_Inf ormation, so 
that the tracks will be played back in the order TrackA, 
TrackB, TrackE, TrackD, TrackC. In this way, the playback 
order of tracks can be easily changed by changing the order 
of the DPL__TK_SRPs in the Def ault_Playlist__Inf ormation . 

15 While the above explanation deals with an editing 

operation that changes the order of tracks, the following 
will describe the following four operations that were 
explained with respect to the changes in the TKIs. These 
operations are a first case (easel) where a track is deleted, 

20 a second case {case2) where a new track is recorded, a third 
case {case3) where two freely selected tracks are combined 
to produce a new track, and a fourth case (case4) where 
a track is divided to produce two new tracks. 

25 
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{17-9_40-3_44A,B} Deletion of a Track 

The following describes easel where a track is deleted. 
FIGS. 44A and 44B show how the Def ault__Playlist , 
TrackManager, and AOB files are updated when, out of the 
5 DefaultPlaylist shown in FIG. 40, DPL_TK_SRP#2 and TKI#2 
are deleted. In these drawings, the same part of an AOB 
is deleted as in FIG. 27 that was used to describe the deletion 
of a TKI . As a result, the second, third, and fourth levels 
in FIG. 44Aand 44B are the same as in FIG. 27 . The difference 
10 with FIG. 27 is that Def ault_Playlist_Inf ormation including 
a plurality of DPL_TK_SRPs is given on the first level, 
in the same way as FIG. 40. 

The present example deals with the case when the user 
deletes TrackB composed of DPL_TK_SRP#2-> 
15 TKI#2 ("AOB002.SA1") that is shown with the thick outline 
in FIG. 44A. In this case, DPL_TK__SRP#2 is deleted from 
Default__Playlist_Information and DPL_TK_SRP#3 to 
DPL__TK_SRP#8 are each moved up by one place in the playback 
order so as to fill the place in the order freed by the 
20 deletion of DPL_TK_SRP#2 . 

When the DPL__TK__SRPs are moved up in this way, the 
final DPL_TK_SRP#8 is set as "Unused". On the other hand, 
the TKI corresponding to the deleted part is set as "Unused" 
as shown in FIGS. 27A and 27B without other TKIs being moved 
25 to fill the gap created by the deletion. Deletion of the 
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TKI is also accompanied by the deletion of the AOB file 
"AOB002.SA1". 

In this way, DPL_TK_SRPs are moved up in the playback 
order but TKIs are not moved, so that in FIG. 44B only the 
5 DPL_TKINs in the DPL__TK_SRPs are updated. For this example, 
the DPL_TKIN in DPL_TK_SRP#2 is set so as to indicate TKI#3 
as shown by the arrow DTll, the DPL_TKIN in DPL_TK_SRP#3 
is set so as to indicate TKI#4 as shown by the arrow DT12, 
the DPL__TKIN in DPL_TK_SRP#4 is set so as to indicate TKI#5, 
10 and the DPL_TKIN in DPL__TK_SRP#5 is set so as to indicate 
TKI#6. The DPL_TKIN in DPL_TK__SRP#8 that has been set at 
"Unused" is set so as to indicate TKI#2, as shown by the 
arrow DT13. 

When a track is deleted, the DPL__TK_SRP used for 
15 following tracks in the playback order are moved up, while 
the TKI corresponding to the deleted track is set at "Unused" 
while remaining in its present position. In this way, an 
editing operation is not accompanied by movement of TKIs, 
which suppresses the processing load when editing tracks. 

20 

{17-9__40-4_45A,B} Assignment of TKIs when Recording Tracks 

The following describes case2 when a new track is 
recorded following the partial deletion of a track. FIGS. 
45A and 45B show how an operation that writes a new TKI 
25 and DPL_TK_SRP is performed when an "Unused" TKI and 
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DPL__TK__SRP are present • 

These drawings are largely the same as FIGS. 28A and 
28B that were used to explain the assignment of a new TKI 
to a TKI set at "Unused". The second^ third, and fourth 
5 levels in FIGS. 45A and 45B are the same as the first three 
levels in FIGS. 28A and 28B. The difference between these 
drawings is that the first levels in FIGS. 45A and 45B show 
the Def ault_Playlist__Inf ormation composed of a plurality 
of DPL__TK_SRP. In FIG. 45A, the DPL_TK_SRP#4 to 
10 DPL_TK___SRP#8 are set as "Unused". On the other hand, in 
FIG. 28 the TKI#2, TKI#4, TKI#5, TKI#7, TKI#8 are set as 
"Unused" . 

While TKIs set at "Unused" are present here and there 
in the TrackManager, the "Unused" DPL_TK_SRPs are positioned 
15 next to one another in the Def ault_Playlist_Inf ormation . 
This results from the used DPL_TK_SRPs being moved up in 
the Def ault_Playlist_Inf ormation as described above, while 
no such moving up is performed for TKIs. 

The following explanation describes the case when 
20 TrackD composed of four AOBs is written • The TKIs for these 
four AOBs are respectively written into the following 
"Unused" TKIs in the TrackManager : TKI#2; TKI#4; TKI#7; 
and TKI#8. 

The DPL_TK_SRPs for these four AOBs are written in 
25 DPL TK SRP#4 to DPL TK SRP#7 in the 
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Def ault_Playlist_Inf ormation . Since these four AOBs 
compose a single track, the DPL_TK_ATR of DPL__TK_SRP#4 is 
set at "Head_of_Track", the DPL_TK_ATRs of DPL_TK_SRP#5 
and DPL_TK_SRP#6 are set at "Middle_of__Track" , and the 
5 DPL__TK__ATR of DPL_TK__SRP#7 is set at "End_of_Track" • 

The DPL__TKIN of DPL__TK_SRP#4 is set at TKI#2, the 
DPL_TKIN of DPL_TK_SRP#5 at TKI#4, the DPL__TKIN of 
DPL_TK_SRP#6 at TKI#7, and the DPL_TKIN of DPL_TK_SRP#7 
at TKI#8. 

10 By setting the DPL___TKINs and DPL_TK_ATRs in this way, 

TKI#2, TKI#4, TKI#7 and TKI#8 are managed as the fourth 

track TrackD. 

In the above processing, a write is performed for 

"Unused" TKIs, though this has no effect on the other TKIs 
15 TKI#1, TKI#2, TKI#3, and TKI#4, as was also the case in 

FIGS. 28A and 28B. 

{17-9_40-5_46A,B} Case3: Combining Tracks 

The following describes the updating of the 
20 Def ault_Playlist__Inf ormation when tracks are combined 
(i.e., in case3) . FIGS. 46A and 46B show one example of 
the combining of tracks. 

These drawings are largely the same as FIGS. 29A and 
29B that were used to explain the combining of TKIs, The 
25 second, third, and fourth levels in FIGS. 4 6A and 4 6B are 
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the same as the first two levels in FIGS. 29A and 29B. The 
difference between these figures is that the first levels 
in FIGS. 4 6A and 4 6B show Def ault_Playlist_Inf ormation^ 
in which DPL_TK_SRP#8 is set at "Unused" and is related 
5 to TKI#2 that is also set at "Unused". When an editing 
operation combining tracks is performed for AOB files and 
TKIs as shown in FIGS. 29A and 29B, the contents of 
DPL_TK_SRP#3 to DPL__TK__SRP#6 are each moved down by one 
and the content of DPL_TK__SRP#7 that is shown with the thick 
10 outline is copied into DPL_TK__SRP#3 as shown in FIGS. 4 6A 
and 4 6B. The TKIs are also updated, as shown in FIGS. 2 9A 
and 2 9B. 

{17-9_40-6_47A,B} Case4 : Division of a Track 

15 The following describes the updating of the 

Def ault_PlaYlist_Inf ormation when a track is divided 
(case4) . 

FIGS. 47A and 47B show one example of the division 
of a track. These drawings are largely the same as FIGS. 

20 33A and 33B that were used to explain the division of TKIs. 
The second and third levels in FIGS. 47A and 47B are the 
same as the first two levels in FIGS. 33A and 33B. The 
difference between these figures is that the first level 
in FIGS. 47A and 47B shows Def ault__Playlist_Inf ormation, 

25 in which DPL TK SRP#8 is set at "Unused" and is related 
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to TKI#2 that is also set at "Unused". 

If, as in FIGS. 33A and 33B, the user indicates the 
division of TKI#3 ("AOB003.SA1") shown with the thick 
outline into two, the positions of DPL_TK_SRP#3 to 
5 DPL_TK_SRP#7 are each moved down by one in the order, and 
a DPL_TK_SRP set at "Unused" is moved within the 
Def ault_Playlist_Inf ormation to the former position of 
DPL_TK_SRP#3. 

This new DPL_TK_SRP#3 is associated with the TKI , TKI#2 , 

10 newly produced by the division. The AOB file "AOB002.SA1" 
associated with TKI#2 stores what was originally the latter 
part of the AOB file "AOB003.SA1" . DPL_TK_SRP#2 is present 
before the DPL_TK_SRP#3 that is associated with TKI#2 and 
is associated with TKI#2 and "AOB002 . SAl" . 

15 This is to say, "AOB002.SA1" and "AOB003.SA1" 

respectively store the latter and former parts of the 
original "AOB003 .SAl", with the DPL_TK_SRP#2 and 
DPL_TK_SRP#3 corresponding to these files indicating that 
these AOBs are to be played back in the order "AOB003.SA1" 

20 and "AOB002 .SAl" . As a result, the latter and former parts 
of the original "AOB003.SA1" will be played back in the 
order former part, latter part in accordance with the 
playback order given in the DPL_TK SRP. 
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{17-9_40"8} Application of the Editing Processing 

By combining the above four editing processes^ a user 
can perform a great variety of editing operations • When, 
for example, a recorded track has an intro over which a 
5 disc jockey has talked, the user can first divide the track 
to separate the part including the disc jockey's voice. 
The user can then delete this track to leave the part of 
the track that does not include the disc jockey. 

This completes the explanation of the navigation data . 
10 The following describes a playback apparatus with a suitable 
composition for playing back the navigation data and 
presentation data described above. 



15 {48-1} External Appearance of the Playback Apparatus 

FIG. 48 shows a portable playback apparatus for the 
flash memory card 31 of the present invention* The playback 
apparatus shown in FIG. 48 has an insertion slot for inserting 
the flash memory card 31, a key panel for receiving user 

20 indications for operations such as playback, forward search, 
backward search, fast forward, rewind, stop etc., and an 
LCD (liquid crystal display) panel. In terms of appearance, 
this playback apparatus resembles other kinds of portable 
music players. 

25 The key panel includes: 
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a "Playlist" key that receives the selection of 
a playlist or a track; 

a " |«" key that receives a skip operation that 
moves the playback position to a start of the current track; 
5 a "»| " key that receives a skip operation that 

moves the playback position to a start of the next track; 

a "«" key and a "»" key that respectively 
receive a backward search operation and a forward search 
operation enable the user to have the playback move quickly 
10 through the current track; 

a "Display" key that receives an operation to 
have still images stored on the flash memory card 31 
displayed; 

a "Rec" key that receives a recording operation; 
15 an "Audio" key for receiving user selections of 

the sampling frequency or of stereo or monaural is to be 
used; 

a "Mark" key that receives user indications that 
mark positions in tracks; and 
20 an "Edit" key that receives user indications for 

the editing of tracks or for the input of track titles. 

{48-2} Improvements Made in This Portable Playback Apparatus 
for the Flash Memory Card 31 

25 The differences between this portable playback 
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apparatus of the flash memory card 31 and a conventional 
portable music player lie in the following four improvements 
(1) to (4) . 

(1) A list of playlist and tracks is shown on the LCD 
5 panel to allow the user to indicate the 

Def ault__Playlist_lnf ormation, a PLI, or separate tracks. 

(2) Keys on the key panel are assigned to the playlists 
and/or tracks displayed on the LCD panel to allow the user 
to select a track or playlist that is to be played back 

10 or edited. 

(3) A time code showing a position in a track is 
displayed on the LCD panel 5 when a track is played back. 

(4) A jog dial is provided to enable the user to set 
a time code for use as playback start time when using the 

15 time search function or as a division boundary when dividing 
a track. 

{48-2_49_50} Improvement (2) 

The following describes improvement (2) in detail. 
20 FIG. 4 9 shows one example of a display screen shown on the 
LCD panel when the user selects a playlist, while FIGs. 
50A to 50E show examples of the displayed content when the 
user selects a track. 

In FIG. 49, the ASCII character strings 
25 "DEFAULTPLAYLIST", "PLAYLIST#1" , "PLAYLIST#2 " , 
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"PLAYLIST#3", and "PLAYLIST#4" represent the default 
playlist and the four playlists stored in the flash memory 
card 31. 

Meanwhile, the ASCII character strings "Tracktl", 
5 "Track#2", "Track#3", "Track#4", "Track#5" represent the 
five tracks that are indicated in the playback order given 
by the default playlist stored in the flash memory card 
31. In FIGS. 4 9and50A, the highlighted Playlist and track 
show the track or Playlist that is currently indicated for 
10 playback or editing. 

If the user presses the "»" key when Track#l is 
indicated for playback within a playback order given by 
the default Playlist displayed on the LCD panel, Track#2 
will be indicated for playback within the list of tracks, 
15 as shown in FIG . SOB . If the user presses the "»" key again, 
Track#3 will be indicated for playback within the list of 
tracks, as shown in FIG. 50C. 

If the user presses the "«" key when Track#3 is 
indicated for playback within a playback order given by 
20 the default Playlist displayed on the LCD panel, Track#2 
will be indicated for playback within the list of tracks, 
as shown in FIG. SOD. As shown in FIG. SOE, if the user 
presses the "Play" key when any of the tracks is indicated, 
the playback of the indicated track will begin, while if 
25 the user presses the "Edit" key, the indicated track will 
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be selected for editing. 

{48-3_51} Improvement (4) 

The following describes improvement (4) in detail* 
5 FIGS. 51A to 51C show an example operation of the jog dial. 
When the user rotates the jog dial by a certain amount, 
the playback time code displayed on the LCD panel will be 
increased or decreased in accordance with this certain 
amount. The example in FIG. 51A shows the case where the 

10 playback time code that is initially displayed on the LCD 
panel is "00:00:20". 

When the user rotates the jog dial counterclockwise 
as shown in FIG. 51B, the playback time code is reduced 
to "0:00:10" in keeping with the amount by which the jog 

15 dial was rotated. Conversely, when the user rotates the 
jog dial clockwise as shown in FIG. 51C, the playback time 
code is increased to "0:00:30" in keeping with the amount 
by which the jog dial was rotated. 

By allowing the user to change the playback time code 

20 in this way, the playback apparatus enables the user to 
indicate any playback time code in a track by merely rotating 
the jog dial. If the user then presses the "Play" key, AOBs 
will be played back starting from a position found according 
to Equation 2 and Equation 3 . 

25 By using the j og dial during a track dividing operation. 
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the user can make fine adjustments to the playback time 
code used as the division boundary. 

{52-1} Internal Construction of the Playback Apparatus 

5 The following describes the internal construction of 

the playback apparatus . This internal construction is shown 
in FIG, 52. 

As shown in FIG. 52, the playback apparatus includes 
a card connector 1 for connecting the playback apparatus 

10 to the flash memory card 31, a user interface unit 2 that 
is connected to the key panel and the jog dial, a RAM 3, 
a ROM 4, a LCD panel 5 having a list frame for displaying 
a list of tracks or playlists and a playback time code frame 
for displaying a playback time code, an LCD driver 6 for 

15 driving the first LCD panel 5, a descrambler 7 for decrypting 
AOB__FRAMEs using a different FileKey for each AOB file, 
an AAC decoder 8 for referring to the ADTS of an AOB__FRAME 
descrambled by the descrambler 7 and decoding the AOB_FRAME 
to obtain PCM data, a D/A converter 9 for D/A converting 

20 the PCM data and outputting the resulting analog signals 
to a speaker or headphone jack, and a CPU 10 for performing 
overall control over the playback apparatus . 

As can be understood from this hardware construction, 
the present playback apparatus has no special hardware 

25 elements for processing the TrackManager and 
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Default_Playlist_Inf ormation. To process the 
TrackManager and Default_Playlist_Inf ormation, a DPLI 
holding area 11, a PLI storing area 12, a TKI storing area 
13, a FileKey storing area 14, and a double buffer 15 are 
5 provided in the RAM 3, while a playback control program 
and an editing control program are stored in the ROM 4. 

{52-2} DPLI Holding Area 11 

The DPLI holding area 11 is an area for continuously 
10 holding Default__Playlist_Inf ormation that has been read 
from a flash memory card 31 connected to the card connector 
1. 

{52_12} PLI Storing Area 12 

15 The PLI storing area 12 is an area that is reserved 

for storing Playlist__Inf ormation that has been selected 
for playback by the user. 

{52-3} TKI Storing Area 13 

20 The TKI storing area 13 is an area that is reserved 

for storing only the TKI corresponding to the AOB file that 
is currently indicated for playback, out of the plurality 
of TKI included in the TrackManager. For this reason, the 
capacity of the TKI storing area 13 is equal to the data 

25 size of one TKI. 
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{52-4} FileKey Storing Area 14 

The FileKey storing area 14 is an area that is reserved 
for storing only the FileKey corresponding to the AOB file 
5 that is currently indicated for playback^ out of the 
plurality of FileKeys included in "AOBSAl.KEY" in the 
authentication region . 

{52-5} Double Buffer 15 

10 The double buffer 15 is an input/output buffer that 

is used when an input process, which successively inputs 
cluster data (data that is stored in one cluster) read from 
the flash memory card 31, and an output process, which reads 
AOB_FRAMEs from cluster data and successively outputs the 

15 AOB_FRAMEs to the descrambler 7 , are performed in parallel . 

The double buffer 15 successively frees the regions 
that were occupied by cluster data that has been outputted 
as AOB_FRAMEs and so secures regions for storing the next 
clusters to be read. This is to say, regions in the double 

20 buffer 15 are cyclically secured for storing cluster data 
using ring pointers. 

{52-5_53_54A,B} Input and Output by the Double Buffer 15 

FIG. 53 shows how input and output are performed for 
25 the double buffer 15. FIGS ♦ 54A and 54B show how regions 
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in the double buffer 15 are cyclically secured for storing 
cluster data using a ring pointers. 

The arrows pointing downward and to the left are 
pointers to write addresses for cluster data, which is to 
5 say, the write pointer. The arrows pointing upward and to 
the left are pointers to read addresses for cluster data, 
which is to say, the read pointer. These pointers are used 
as the ring pointer. 

10 {54-6_53} 

When a flash memory card 31 is connected to the card 
connector 1, cluster data in the user region of the flash 
memory card 31 is read out and stored in the double buffer 
15 as shown by the arrows wl and w2 . 
15 The read cluster data is successively stored into the 

positions in the double buffer 15 shown by the write pointers 
wpl and wp2 . 

{52-7_54A} 

20 Of the AOB_Frames included in the cluster data stored 

in this way, the AOB_Frames present at the positions ® 
(D(3)(3XD(D(7)®(i) that are successively indicated by the read 
pointer are outputted one at a time to the descrambler 7 
as shown by the arrows rl, r2, r3, r4, r5 .... 

25 In the present case, the cluster data 002 and 003 is 
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stored in the double buffer 15 and the read positions ® 
dXD® are successively indicated by the read pointer, as 
shown in FIG. 53. When the read pointer reaches the read 
position (D, all of the AOB__FRAMEs included in cluster 002 
5 will have been read, so that cluster 004 is read and, as 
shown by the arrow w6 in FIG. 54A, is overwritten into the 
region that was previously occupied by cluster 002. 
{52-8_54B} 

The read pointer then advances to the read positions 
10 (D and (Z)/ and eventually reaches the read position (D, at 
which point all of the AOB_FRAMEs included in cluster 003 
will have been read, so that cluster 005 is read and, as 
shown by the arrow w7 in FIG. 54B, is overwritten into the 
region that was previously occupied by cluster 003. 
15 The output of an AOB_FRAME and the overwriting of cluster 

data are repeatedly performed as described above, so that 
the AOB__FRAMEs included in an AOB file are all successively 
outputted to the descrambler 7 and AAC decoder 8. 

20 {52-9_55-58) Playback Control Program Stored in the ROM 
4 

The following describes the playback control program 
stored in the ROM 4. 

FIG. 55 is a flowchart showing the processing in the 
25 AOB file reading procedure. FIGS. 56, 57, and 58 are 
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flowcharts showing the processing in the AOB_FRAME output 
procedure. 

{52-9_55"l} 

5 These flowcharts use the variables w, z, and x. 

The variable w indicates one of the plurality of DPL_TL_SRPs . 
The variable z indicates an AOB file recorded in the user 
region, the TKI corresponding to this AOB file, and the 
AOB included in this AOB file. The variable y indicates 
10 an AOB_ELEMENT included in the AOB#z indicated by the 
variable z . The variable x indicates an AOB_FRAME included 
in the AOB_ELEMENT#y indicated by the variable y. The 
following first explains the processing in the AOB file 
read procedure, with reference to FIG. 55. 

15 

{52-9_55-2} 

In step SI, the CPU 10 reads the PlaylistManager and 
displays a list including the Def ault_Playlist_Inf ormation 
and the PLIs. 

20 In step S2, the CPU 10 waits for an indication to play 

back AOBs in accordance with either the 
Def ault_Playlist_Inf ormation or one of the PLIs. 

When the Def ault_Playlist_Inf ormation is indicated, 
the processingmoves f romstep S2 to step S3 where the variable 

25 w is initialized (#w^l) and then to step S4 where the TKI#z 
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indicated by the DPL__TKIN corresponding to DPL_TK_SRP#w 
in the Def ault_Playlist_Inf ormation is specified and only 
this TKI#z is read from the flash memory card 31 and stored 
into the TKI storing area 13. 
5 In step S5, an AOB f ile#z with the same number as TKI#z 

is specified. In this way, the AOB file that is to be played 
back is finally specified. 

The specified AOB file is in an encrypted state and 
needs to be decrypted, so that steps S6 and S7 are performed. 

10 In step S6, the playback apparatus accesses the 

authentication region and reads the FileKey#z that is stored 
in a FileKey__Entry#z in the encryption key storing file, 
the FileKey__Entry#z having the same number as the specified 
AOB file. In step S7, the CPU 10 sets the FileKey#z in the 

15 descrambler 7 . This operation results in the FileKey being 
set in the descrambler 7, so that by successively inputting 
AOB_FRAMEs included in the AOB file into the descrambler 
7, the AOB_FRAMEs can be successively played back. 

20 {52"9_55-3} 

After this, the playback apparatus successively reads 
the clusters that store the AOB file . In step S8 , the "first 
cluster number in the file" is specified for the AOB_file#z 
in the directory entry. In step S9, the CPU 10 reads the 
25 data stored in this cluster from the flash memory card 31. 
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In step SIO, the CPU 10 judges whether the cluster number 
in the FAT value is "FFF". If not, in step Sll the CPU reads 
the data stored in the cluster indicated by the FAT value, 
before returning to step SIO. 
5 When the playback apparatus reads the data stored in 

any of the clusters and refers to the FAT value corresponding 
to this cluster, the processing in steps SIO and Sll will 
be repeated so long as the FAT value is not set at "FFF". 
This results in the playback apparatus successively reading 
10 clusters indicated by the FAT values. When the cluster 
number given by a FAT value is "FFF", this means that all 
of the clusters composing the AOB file#z have been read, 
so that the processing advances from step SIO to step S12. 
{52-9_55-4} 

15 In step S12, the CPU 10 judges whether the variable#w 

matches the total number of DPL__TK_SRPs . If not, the 
processing advances to step S13, where the variable#w is 
incremented {#w^#w+l) before the processing returns to step 
S4 . In step S4 , the playback apparatus specifies TKI#z which 

20 is indicated by the DPL_TKIN#w of DPL_TK_SRP#w in the 
Def ault_Playlist_Inf ormation, and writes only TKI#z into 
the TKI storing area 13. The TKI that was used up to this 
point will be still stored in the TKI storing area 13, though 
this current TKI will be overwritten by TKI#z that is newly 

25 read by the CPU 10. 
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This overwriting results in only the latest TKI being 
stored in the TKI storing area 13. Once the TKI has been 
overwritten, the processing in steps S5 to S12 is repeated 
for the AOB file#z. Once this processing has read all of 
the TKI and AOB files corresponding to all of the DPL_TK__SRPs 
included in the Def ault_Playlist_Inf ormation;. the variable 
#z will match the total number of DPL_TK_SRP so that the 
judgement "Yes" is given in step S12 and the processing 
in this flowchart ends. 

{52-9__56_57_58} Output Processing for an AOB_FRAME 

In parallel with the AOB file reading procedure, the 
CPU 10 performs the AOB_FRAME output procedure in accordance 
with the flowcharts shown in FIGS. 56;. 57, and 58. In these 
flowcharts, the variable "play_time" shows how long playback 
has been performed for a current track, which is to say, 
the playback time code. The time displayed in the playback 
time code frame on the LCD panel 5 is updated in accordance 
with changes to this playback time code. Meanwhile, the 
variable "play__data" represents the length of the data has 
been played back for the current track. 

{52-9_56-l} 

In step S21, the CPU 10 monitors whether cluster data 
for the AOB file#z has accumulated in the double buffer 



118 



15. This step S21 willbe repeatedlyperformed until cluster 
data has accumulated, at which point the processing advances 
to step S22 where the variables x and y are initialized 
(#x^l, #y-l) . After this, in step S23 the CPU 10 searches 
5 the clusters for AOB file #z and detects the AOB_FRAME#x 
in the AOB_ELEMENT#y that is positioned no earlier than 
the Data_Offset given in the BIT#2 included in TKI#z. In 
this example, it is assumed that the seven bytes starting 
from the SZ_DATA are occupied by the ADTS header. By 

10 referring to the ADTS header, the data length indicated 
by the ADTS header can be recognized as audio data* The 
audio data and ADTS header are read together and are outputted 
to the descrambler 7. The descrambler 7 decrypts the 
AOB__FRAMEs, which are then decoded by the AAC decoder 8 

15 and reproduced as audio, 

{52"9_56-2} 

After this detection, in step S24 the AOB__FRAME#x is 
outputted to the descrambler 7, and in step S25 the variable 

20 play_time is incremented by the playback period of the 
AOB__FRAME#x and the variable play__data is incremented the 
amount of data corresponding the AOB__FRAME#x • Since the 
playback time of AOB_FRAME is 20msec in the present case, 
20msec is added to the variable "play_time". 

25 Once the first AOB_FRAME has been outputted to the 
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descrambler 7, in step S2 6 the playback apparatus refers 
to the ADTS header of AOB__FRAME#x and specifies where the 
next A0B_FR7\ME is. In step S21 , the playback apparatus 
increments the variable#x (#x<— #x+l) and sets AOB_FRAME#x 
5 as the next AOB_FRAME , In step S28 , AOB_FRAME#x is inputted 
into the descrambler 7. After this, in step S29, the 
variable play_time is incremented by the playback period 
of the AOB_FRAME#x and the variable play_data is incremented 
the amount of data corresponding the AOB_FRAME#x, After 

10 incrementing AOB_FRAME#x, in step S30 the CPU 10 judges 
whether the variable #x has reached the value given in 
FNs__lst_TMSRTE. 

If the variable #x has not reached the value in 
FNs_lst_TMSRTE, in step S31 the playback apparatus checks 

15 whether the user has pressed any key aside from the "Play" 
key, and then returns to step S2 6. The playback apparatus 
hereafter repeats the processing in steps S26 to S31 until 
the variable #x reaches the value in FNs_lst_TMSRTE or until 
the user presses any key aside from the "Play" key. 

20 When the user presses a key aside from the "Play" key, 

the processing in this flowchart ends and suitable 
processing for the pressed key is performed. When the 
pressed key is the "Stop" key, the playback procedure stops, 
while when the pressed key is the "Pause" key, the playback 

25 is paused. 
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{52-9_57-l} 

On the other hand, when the variable #x reaches the 
value in FNs_lst_TMSRTE, the judgement "Yes" is made in 
step S30, and the processing proceeds to step S32 in FIG. 
5 57. Since all of the AOB_FRAMEs included in the present 
AOB_ELEMENT will have been inputted into the descrambler 
7 in the processing between step S26 to S30, in step S32 
the variable #y is incremented to set the next AOB_ELEMENT 
as the data to be processed and the variable #x is initialized 

10 (#y^#y+l,#x<-l) . 

After this, in step S33 the playback apparatus refers 
to the TKTMSRT and calculates the first address of the 
AOB_ELEMENT#y. 

The playback apparatus then performs the procedure 

15 made up of steps S34 to S42. This procedure reads the 
AOB__FRAMEs included in an AOB__ELEMENT one after another, 
and so can be said to resemble the procedure made up of 
steps S24 to S31. The difference with the procedure made 
up of steps S24 to S31 is the condition by which the procedure 

20 made up of steps S24 to S31 ends is whether the variable 
#x has reached the value shown by "FNs__lst_TMSRTE" , while 
the condition by which procedure made up of steps S34 to 
S42 ends is whether the variable #x has reached the value 
shown by "FNs_iy[iddle__TMSRTE" . 

25 When the variable #x reaches the value shown by 
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"FNs_Middle_TMSRTE", the loop procedure made up of steps 
S34 to S42 ends, the judgement "Yes" is given in step S41 
and the processing advances to step S43. In step S43, the 
CPU 10 increments the variable #y and initializes the 
5 variable #x (#y^#y+l, #x^l) . After this, in step S44 the 
variable y judges whether the variable #y has reached a 
value that is equal to one less than the 
TotalTMSRT__entry_Number in the TMSRT_Header in the TKI#z, 
When the variable #y is lower than 

10 (TotalTMSRT_entry_Number-l) , the AOB_ELEMENT#y is not the 
final AOB_ELEMENT, so that the processing returns from step 
S44 to step S32 and the loop procedure of step S32 to step 
S42 is performed. When the variable #y reaches 
(TotalTMSRT_entry__Number-l) the read procedure can be 

15 assumed to have proceeded as far as the penultimate 

AOB__ELEMENT , SO that the judgement "Yes" is given in step 
S44 and the processing advances to step S45 in FIG. 58. 

{52-9_57-2} 

20 The procedure composed of steps S45 to S54 resembles 

the procedure composed of steps S33 to S42 in that each 
of the AOB_FRAMEs in the final AOB_ELEMENT are read. 

The difference with the procedure composed of steps 
S33 to S42 is that while the loop procedure composed of 

25 steps S33 to S42 ends when it is judged in step S41 that 
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the variable #x has reached the value in "FNs_Middle__TMSRTE" , 
the loop procedure composed of steps S45 to S54 ends when 
it is judged in step S53 that the variable #x has reached 
the value in "FNs_Last_TMSRTE" and the variable play__data 
showing the size of the data that has hitherto been read 
has reached the value given as "SZ__DATA". 

The procedure composed of steps S49 to S54 is repeated 
until the conditions in step S53 are satisfied, at which 
point the judgement "Yes" is given in step S53 and the 
processing advances to step S55. In step S55, the CPU 10 
increments the variable #z (#2^#z+l) before the processing 
returns to step S21 where the CPU 10 waits for the next 
AOB file to accumulate in the double buffer 15. Once this 
happens, the processing advances to step S22 and the 
procedure composed of steps S22 to step S54 is repeated. 
This means that the TKI indicated by the DPL_TKIN of the 
next DPL_TK_SRP is specified and the AOB file corresponding 
to this TKI, which is to say, the AOB file with the same 
number as the TKI, is specified. 

After this, the playback apparatus accesses the 
authentication region and specifies the FileKey, out of 
the FileKeys in the encryption key storing file, that has 
the same number as the TKI, before reading this FileKey 
and setting it in the descrambler 7. As a result, the 
AOB_FRAMEs included in the AOB file having the same number 
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as the TKI are successively read and played back. 

{52-9_57-3__59} Updating of the Playback Time Code 

FIGS. 59A to 59D show how the playback time code 
displayed in the playback time code display frame of the 
LCD panel 5 is increased in accordance with the updating 
of the variable play_time. In FIG. 59A, the playback time 
code is "00:00:00.000", though when the playback of 
A0B_FRAME#1 ends, the playback period 20msec of A0B_FRAME#1 
is added to the playback time code to update it to 
"00:00:00.020", as shown in FIG. 59B. When the playback 
of A0B_FRAME#2 ends, the playback period 20msec of 
A0B_FRAME#2 is added to the playback time code to update 
it to "00:00:00.040", as shown in FIG. 59C. In the same 
way, when the playback of A0B_FRAME#6 ends, the playback 
period 20msec of A0B_FRAME#6 is added to the playback time 
code to update it to "00:00:00.120", as shown in FIG. 59D. 

This completes the description of the AOB_FRAME output 
procedure . 

In step S31 of the flowchart in FIG. 56, if the user 
presses a key aside from the "Play" key, the processing 
in this flowchart is terminated. The processing that 
accompanies a pressing of "Stop" or "Pause" key has already 
been described, though when the user presses one of the 
keys provided to have the playback apparatus perform special 
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playback, the processing in this flowchart, or in the 
flowcharts shown in FIGS. 56, 57, or 58 is terminated and 
suitable processing for the pressed key is performed. 

The following describes the procedure executed by the 
CPU 10 (1) when performing the forward search function in 
response to the user pressing the "»" key and (2) when 
performing the time search function in response to the user 
operating the jog dial after pressing the "Pause" or "Stop" 
key. 

{52-10_60} Forward Search Function 

FIG. 60 is a flowchart showing the procedure executed 
by the CPU 10 when performing the forward search function. 
When the user presses the "»" key, the judgement "Yes" 
is given in step S31, step S42 or step S54 in the flowcharts 
in FIGS . 56, 57 and 58 and the CPU 10 performs the processing 
in the flowchart of FIG. 60. 

In step S61, the AOB_FRAMEs #x to #(x+f(t)-l) are 
inputted into the descrambler 7. Here "t" represents the 
intermittent playback period, f (t) represents the number 
of frames corresponding to the intermittent playback period, 
and d(t) represents the amount of data corresponding to 
the intermittent playback period. In step S 62, the variable 
play_time showing the playback elapsed time, and the 
variable play_data showing the playback data amount are 
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respectively updated using intermittent playback period 
"t", the number of frames f (t) corresponding to intermittent 
playback period, and the amount of data d(t) corresponding 
to the intermittent playback period (x^x+f (t) , 
5 play_time^play__time+t, play__data*-play__data-i-d (t) ) . Note 
that the intermittent playback period will generally be 
240 msec (equivalent to the playback period of twelve 
AOB_FRAMEs) . 

10 {52-10_60-l_61A,B} 

FIGS. 61A and 61B show the incrementing of the playback 
time code during a forward search operation. FIG. 61A shows 
the initial value of the playback time code, with the playback 
point being the A0B__FRAME#1 in A0B__ELEMENT#51 . 

15 The playback time code in this case is "00:00:01.000". 

When the first to twelve AOB_FRAMEs have been inputted into 
the descrambler 7 as the intermittent playback period, the 
playback period of twelve AOB_FRAMEs (i.e., 240msec) is 
added to the playback time code so that the playback time 

20 code becomes "00:00:01.240", as shown in FIG. 61B. 

{52"10_60-2} 

After this updating, in step S63 the CPU 10 compares 
the incremented variable #x with the total number of frames 
25 in AOB_ELEMENT#y and j udges whether the incremented variable 
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#x is within the total number of frames in AOB__ELEMENT#y . 

As mentioned earlier, the number of frames in an 
AOB_ELEMENT positioned at the start of an AOB is 
"FNs_lst_TMSRTE", the number of frames in an AOB__ELEMENT 
5 positioned in a central part of an AOB is "FNs__Middle_TMSRTE", 
and the number of frames in an AOB_ELEMENT positioned at 
the end of an AOB is "FNs_Last_TMSRTE" . 

The CPU 10 performs the above judgement by comparing 
an appropriate one of these values with the variable #x. 

10 When the variable x is not within the present AOB_ELEMENT#y, 
the CPU 10 then judges in step S64 whether there is an 
AOB_ELEMENT that follows the AOB_ELEMENT#y . 

When the AOB_ELEMENT#y is the final AOB^ELEMENT in an 
AOB_BLOCK, there will be no AOB_ELEMENT that follows the 

15 AOB__ELEMENT#y, so that the judgement "No" is given in step 
S64 and the processing in the present flowchart ends • 
Conversely, when an AOB_ELEMENT that follows the 
AOB_ELEMENT#y exists, in step S65 the variable #x is reduced 
by the number of AOB_FRAMEs in the AOB__ELEMENT#y and in 

20 step S66 the variable#y is updated (#y^#y+l) . As a result, 
the variable#x will now indicate the frame position of a 
frame in the next AOB_ELEMENT#y indicated by the updated 
variable #y. Conversely, when the variable #x indicates 
an AOB__FRAME that is present in the current AOB_ELEMENT 

25 (S63:Yes), the processing in steps S64-S66 is skipped and 
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the processing advances to step S67. 
{52-10_60-3} 

After this, the variables #x, play_time, and play___data 
5 are updated in accordance with the intermittent skip period. 
The period "skip^time" that is equivalent to the 
intermittent skip period is two seconds, the number of frames 
that are equivalent to this skip_time is given as 
f (skip__time) and the amount of data that is equivalent to 
10 this skip_time is given as d (skip^time) . In step S67, these 
values are used to update the variables play_time, and 
rfl play_data (#x^#x+f (skip_time) , play_time^ 
3 play_time+skip_time, and play_data^ 
?S play_data+d (skip__time) ) . 

15 

{52-10_60-4_61C} 

m As shown in FIG. 61C, the intermittent skip period is 

Q added to the variable#x showing a frame position within 
the A0B_ELEMENT#51 . When the updated variable #x exceeds 
20 the number of frames in A0B_ELEMENT#51, the variable #y 
is updated to indicate the next AOB_ELEMENT and the number 
of frames in the A0B_ELEMENT#51 is subtracted from the 
variable #x. As a result, the variabletx will now indicate 
a frame position within the A0B_ELEMENT#52 indicated by 
25 the updated variable #y. The value 2.000 (=2sec) is then 
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added to the present value "00:00:01.240" of the playback 
time code so that it becomes "00 : 00 : 03 • 240" . The variable 
#x is updated by calculating (3240msec-2000msec) /20msec) 
to give the value "62", and so indicates the AOB_FRAME#62 
5 in the AOB__ELEMENT#52 . 

{52"10_60-5_61(d) } 

Once the AOB_FRAME#62 in the AOB_ELEMENT#52 has been 
inputted into the descrambler 7, the playback time code 
10 is updated as shown in FIG. 61D by adding "0.240" to the 
:D present value of "00:00:03.240" to give "00:00:03.480". 
:Xl In step S67, the variables are updated in accordance 

with the intermittent skip time and then the processing 
% in steps S68 to S71 are performed. This processing in steps 
15 S68 to S71 is the same as the processing in steps S63 to 
-f; S66 and so updates the variable#x by a number of frames 
IP that is equivalent to the intermittent skip time "skip_time", 
before checking whether the variable#x still indicates an 
AOB_FRAME within the present AOB_ELEMENT#y . If not, the 
20 variable #y is updated so that the next AOB^ELEMENT is set 
as the AOB__ELEMENT#y and the variable#x is converted so 
as to indicate a frame position in this next AOB__ELEMENT . 

Once the variables #x and #y have been in accordance 
with the intermittent playback time and intermittent skip 
25 time, in step S72 the CPU 10 refers to the TKTMSRT and 
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calculates the start address for the AOB_ELEMENT#y . Then, 
in step S73, the CPU 10 starts to search for an ADTS header 
starting from the start address of the AOB__ELEMENT#y to 
detect the AOB_FRAME#x. In step S74, the CPU 10 judges 
5 whether the user has pressed any key aside from the forward 
search key. If not, the AOB_FRAMEs from the AOB_FRAME#x 
to the AOB_FRAME#x+f (t) -1 are inputted into the descrambler 
7, and the processing in steps S62 to S73 is repeated. 
The above procedure increments the variables #x and 
10 #y that indicate the AOB__FRAME#x and AOB_ELEMENT#y, and 
so advances the playback position. After this, if the user 
presses the "Play" key, the judgement "No" is given in FIG, 
74 and the processing in the present flowchart ends. 

15 {52-11} Execution of the Time Search Function 

The following describes the processing performed when 
the time search function is used. First, the tracks in the 
Def ault_Playlist_Inf ormation are displayed and the user 
indicates a desired track. When this track has been 

20 indicated and the user has operated the j og dial , the playback 
time code is updated. If the user then presses the "Play" 
key, the playback time code at that point is used to set 
a value in the variable "Jmp_Entry" in seconds. 

A judgement is then made as to whether the indicated 

25 track is composed of a plurality of AOBs or a single AOB. 
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When the track is composed of a single AOB^ the variables 
#y and #x are calculated so as to satisfy Equation 2 . After 
this, a search for the A0B__FR7yyiE#x is started from the address 
in the {y+2) position in the TKTMSRT corresponding to this 
5 AOB, Once this AOB_FRAME#x has been found, playback starts 
from AOB_FRAME#x. 

{52-12} 

When the track is composed of a plurality of AOBs, the 
10 variables #n (indicating an AOB) , #y and #x are calculated 
C so as to satisfy Equation 3. After this^. a search for the 
is AOB_FRAME#x is started from the address in the (y+2)^^ 
S position in the TKTMSRT corresponding to AOB#n. Once this 

AOB_FRAME#x has been found, playback starts from 
% 15 AOB_FRAME#x. 

■f^ The following describes the case when playback is 

commenced from an arbitrary position with an AOB where the 

n "FNs_lst_TMSRTE" in the BIT is "80 frames", 

"FNs_Middle__TMSRTE" in the BIT is "94 frames", and the 
20 "FNs_Last_TMSRTE" in the BIT is "50 frames", 

{52-13_62A,B} 

As one specific example of when the time search function 
is used, the following describes how the AOB_ELEMENT and 
25 frame position from which playback should start are 
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specified when a playback time code is indicated using the 
jog dial. 

As shown in FIG. 62A, the user holds the playback 
apparatus in his/her hand and rotates the jog dial with 
5 his/her right thumb to indicate the playback time code 
"00 : 04 : 40 . 000 (=280sec) " . When the BIT in the TKI for this 
AOB is as shown in FIG. 62B, Equation 2 is used as follows 

280sec= (FNs_lst_TMSRTE+ (FNs_Middle_TMSRTE*y) +x) *20msec 
10 =(80+ (94^148) +8) *20msec 

so that the Equation 2 is satisfied for the values y=148 
and x=8. 

Since y=148, the entry address of the AOB_ELEMENT#150 
15 (=148+2) is obtained from the TKTMSRT. Playback from the 
indicated playback time code 00:04: 40 .000 (=280 . OOsec) can 
then be performed by starting the playback at the eighth 
AOB_FRAME from this entry address. 

20 { 52 -14_63_64_65 } 

This completes the explanation of the processing of 
the CPU 10 in response to the user pressing the "Play" key. 
The following describes the editing control program stored 
in the ROM 4 • This editing control program is executed when 
25 the user presses the "Edit" key, and contains the procedures 



132 



shown in FIGS. 63, 64, and 65. The following describes the 
processing in this program with the flowcharts shown in 
these drawings. 



5 {52-14__63-l} Editing Control Program 

When the user presses the "Edit" key, an interactive 
screen is displayed in step SlOl in FIG. 63 to ask the user 
which of the three fundamental editing operations "deletion" , 
"division" and "combining" is to be performed. In step S102, 
_ 10 the CPU 10 judges what operation has been made by the user 
C in response to the interactive screen. In the present 
111 example, it is assumed that the "|«" and "»|" keys on the 
key panel are also used as indicating "Up" and "Down" cursor 
^ operations, (i.e., these keys are used as "Up" and "Down" 
■L.15 cursor keys) . When the user indicates a "deletion" 

operation, the processing proceeds to the loop procedure 
composed of steps S103 and S104. 
.Q In step S103, the CPU 10 judges whether the user has 

pressed the "i«" or "»j" key. In step S104, the CPU 10 
20 judges whether the user has pressed the "Edit" key. When 
the user has pressed the "i«" or "»|" key, the processing 
advances from step S103 to S105, where the indicated track 
is set as the track to be edited. On the other hand, when 
the user has pressed the "Edit" key, the indicated track 
25 is set as a track to be deleted. The processing shown in 



133 



FIG. 44 is executed, so that the TKI_BLK_ATR of each TKI 
for the indicated track is set at "Unused" to delete the 
indicated track. 

5 {52"14_63-2} Combining Process 

When the user selects the coinbining process, the 
processing proceeds from step S102 to the loop procedure 
composed of steps S107 to S109. In the loop procedure 
composed of steps S107 to S109, the playback apparatus 

10 receives user inputs via the "|«", "»(", and "Edit" keys. 
When the user presses the "|«" or "»|" key, the processing 
advances from step S107 to step SllO where the indicated 
track is highlighted on the display. When the user presses 
the "Edit" key, the judgement "Yes" is given in step S108 

15 and the processing advances to step Sill. In step Sill, 
the currently indicated track is set as the first track 
to be used in this editing process and the processing returns 
to the loop procedure composed of steps S107 to S109. 

When a second track has been selected for editing, 

20 the judgement "Yes" is given in step S109, and the processing 
advances to step S112. In step S112, the CPU 110 refers 
to the BITS in the TKIs of the former and the latter tracks 
and judges what kind of AOBs (Typel or Type2) are present 
at the respective start and end of each of these tracks 

25 and tracks on either side of these tracks, if present. 
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After identifying the type of each relevant AOB, in 
step S113 the CPU 10 judges whether the arrangement of AOBs 
matches a certain pattern. When the arrangement of AOBs 
matches one of the four patterns shown in FIG. 32A to 32D 
5 where it is clear that three Type2 AOBs will not be present 
consecutively after the combining, the former and latter 
tracks are combined into a single track in step S115, 

In the other words, the operation shown in FIG. 4 6 is 
performed for the TKI and DPL_TK_SRP corresponding to these 
_ 10 AOBs. By rewriting the TKI__BLK___ATRs in the TKIs, the 
;D plurality of tracks selected for editing are combined into 
HI a single track. When the arrangement of AOBs does not match 
\il any of the patterns in FIGS. 32A to 32D, meansing that there 
S will be three or more Type2 AOBs after the combining, the 
i.r, 15 CPU 10 judges that the combined track may cause a buffer 
5;J underflow and so terminates the combining process. 

CI {52-14_64-l} Track Division Process 

When the user indicates that a track is to be divided, 
20 the processing advances from step S102 to the loop procedure 
composed of steps S116 to S117. In the loop procedure 
composed of steps S116 to S117, the playback apparatus 
receives user inputs via the "»|", and "Edit" keys. 

When the user presses the "(«" or "»|" key, the 
25 processing advances from step S116 to step S118 where the 
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indicated track is set as the track to be edited. When the 
user presses the "Edit" key, the judgement "Yes" is given 
in step S117 and the processing advances to step S119. 
In step S119, the indicated track is determined as the 
5 track to be edited and the processing advances to step S120 
where the playback of this track is commenced. In step S121, 
the playback apparatus receives a user input via the "Mark" 
key. 

When the user presses the "Mark" key, the playback of 

10 the track is paused and the processing advances to the loop 
procedure composed of steps S122 and S123. In step S122, 
the playback apparatus receives user operations made via 
the jog dial. When the user rotates the jog dial, the 
playback time code is updated in step S124 in accordance 

15 with the rotation of the jog dial. 

After this, the loop procedure composed of steps 8122 
and S123 is repeated. If the user presses the "Edit" key, 
the processing proceeds from step S123 to step S125, where 
the playback time code displayed when the user pressed the 

20 "Edit" key is set as the division boundary. Note that an 
"Undo" function may be provided for this setting of the 
division boundary to allow the user to invalidate the 
selected division boundary. 

After this, the processing explained with reference 

25 to FIG. 47 is executed in step S126 to update the DPLI and 
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TKI so as to divide the selected track. 

{52-14_65-"l} Process Setting a Playlist 

When the user chooses to set a Playlist, the processing 
5 switches to the procedure shown by the flowchart in FIG. 
65. In this flowchart, the variable k given in this 
flowchart is used to indicate the position of a track in 
the playback order given by the Playlist that is being edited* 
The flowchart in FIG. 65 starts with this variable k being 
10 initialized to "1" in step S131, before the processing 
advances to the loop procedure composed of steps S132 to 
m S134. 

4? In the loop procedure composed of steps S132 to S134, 

the playback apparatus receives user operations made via 
;L.15 the "Edit", and "Stop" keys. When the user 

J::; presses the "i«" or "»| " key, the processing advances from 
ffl step S132 to step S135 where a new track is indicated in 
Q accordance with the pressing of the "i«" or "»|" key* If 
the user presses the "Edit" key, the judgement "Yes" is 
20 given in step S133 and the processing advances to step S136. 

In step S136, the track indicated when the user presses 
the "Edit" key is selected as the kth track in the playback 
order. After this, in step S137 the variable k is 
incremented and the processing returns to the loop procedure 
25 composed of steps S132 to S134. This procedure is repeated 
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so that the second, third and fourth tracks are successively 
selected. If the user presses the "Stop" key have specified 
several tracks that are to be played back in the specified 
order as a new Playlist, the processing advances from step 
5 S134 to step S138 where a PLI composed of PL___TK__SRPs that 
specify the TKIs corresponding to these tracks is generated, 

{66-1} Recording Apparatus 

The following describes one example of a recording 
10 apparatus for the flash memory card 31. FIG, 66 shows one 
example of a recording apparatus . This recording apparatus 
can be connected to the Internet, and is a standard personal 
computer that can perform reception when an encrypted 
SD-Audio directory is sent via communication lines to the 
15 recording apparatus by an electronic music distribution 
service, or when an audio data transport stream is sent 
via communication lines to the recording apparatus by an 
electronic music distribution service. 

20 {67-1} Hardware Composition of the Recording Apparatus 

FIG. 67 shows the hardware composition of the present 
recording apparatus . 

As shown in FIG. 67^ the recording apparatus includes 
a card connector 21 for connecting the recording apparatus 
25 to the flash memory card 31, a RAM 22^ a non-removable disk 
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apparatus 23 for storing a recording control program 
that perforins overall control over the recording apparatus, 
an A/D converter 24 that A/D converts audio inputted via 
a microphone to produce PCM data, an ACC encoder 25 for 
5 encoding the PCM data in units of a fixed time and assigning 
ADTS headers to produce AOB_FRAMEs, a scrambling unit 2 6 
for encrypting the AOB_FRAMEs using a different FileKey 
for each AOB_BLOCK, a modem apparatus 27 for receiving an 
audio data transport stream when an encrypted SD-Audio 

10 directory is sent via communication lines to the recording 
apparatus by an electronic music distribution service, or 
when an audio data transport stream is sent via communication 
lines to the recording apparatus by an electronic music 
distribution service, a CPU 28 for performing overall 

15 control over the recording apparatus, a keyboard 29 for 
receiving inputs made by the user, and a display 30. 

{67-2} Input Circuits RTl to RT4 

When an encrypted SD-Audio directory, which is to be 
20 written in the data region and the authentication region, 
is sent via communication lines to the recording apparatus 
by an electronic music distribution service, the recording 
apparatus can write the encrypted SD-Audio directory into 
the data region and authentication region of the flash memory 
25 card 31 as soon as the encrypted SD-Audio directory has 
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been properly received. 

However, (1) when an audio data transport stream that 
is not in the form of SD-Audio directory is sent to the 
recording apparatus by an electronic music distribution 
5 service, (2) when data is inputted into the recording 
apparatus in PCM format, or (3) when analog audio is recorded 
by the recording apparatus, the recording apparatus uses 
the following four input routes to write an audio data 
transport stream onto the flash memory card 31, 
10 As shown in FIG. 67, the four input routes RTl, RT2, 

RT3, and RT4 are used to input an audio data transport stream 
when an audio data transport stream is stored in the flash 
memory card 31. 

15 {67-3} Input Route RTl 

The input route RTl is used when an encrypted SD-Audio 
directory is sent via communication lines to the recording 
apparatus by an electronic music distribution service, or 
when an audio data transport stream is sent via communication 

20 lines to the recording apparatus by an electronic music 
distribution service. In this case, the AOB_FRAMEs 
included in the transport stream are encrypted so that a 
different FileKey is used for the AOB_FRAMEs in different 
AOBs . Since there is no need to encrypt or encode an 

25 encrypted transport stream, the SD-Audio directory or audio 



140 



data transport stream can be stored directly into the RAM 
22 in its encrypted state. 

{67-4} Input Route RT2 

5 Input route RT2 is used when audio is inputted via a 

microphone. In this case, the audio inputted via the 
microphone is subjected to A/D conversion by the A/D 
converter 2 4 to produce PCM Data . The PCM data is then encoded 
by the AAC encoder 25 and assigned ADTS headers to produce 
10 AOB_FRAMEs. After this, the scrambling unit 2 6 encrypts 
the AOB__FRAMEs using a different FileKey for each AOB__FRAMEs 
in different AOB_FILEs to produce encrypted audio data. 
After this, the encrypted audio data is stored in the RAM 
22. 

15 

{67-5} Input Route RT3 

Input route RT3 is used when PCM data read from a CD 
is inputted into the recording apparatus. Since data is 
inputted in PCM format, the data can be inputted as it is 
20 into the AAC encoder 25. This PCM data is encoded by the 
ACC encoder 25 and assigned ADTS headers to produce 
AOB_FRAMEs . 

After this, the scrambling unit 2 6 encrypts the 
AOB_FRAMEs using a different FileKey for the AOB_FRAMEs 
25 in different AOBs to produce encrypted audio data. After 
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this, the encrypted audio data is stored in the RAM 22. 

{67-6} Input Route RT4 

The input route RT4 is used when a transport stream 
5 inputted via one of the three input routes RTl, RT2^ and 
RT3 is written into the flash memory card 31. 

This storing of audio data is accompanied by the 
generation of TKIs and Def ault__Playlist_Inf ormation. In 
the same way as the playback apparatus, the main functioning 
10 of the recording apparatus is stored in the ROM. This is 
to say, a recording program that includes the characteristic 
processing of the recording apparatus, which is to say, 
the recording of AOBs, the TrackManager, and the 
PlaylistManager, is stored in the non-removable disk 
15 apparatus 23. 

{67-7_68} Processing of the Recording Apparatus 

The following describes the processing in the recording 
procedure that writes a transport stream in the flash memory 
20 card 31 via the input routes RTl, RT2, RT3 and RT4, with 
reference to the flowchart in FIG. 68 that shows this 
processing. 

The variables "Frame_N umber" and "Data__Size" used in 
this flowchart are as follows . The variable Frame__Number 
25 is used to manage the total number of AOB_FRAMEs that have 
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already been recorded in an AOB__FILE. The variable 
Data_Size is used to manage the data size of the AOB_FRAMEs 
that have already been recorded in the AOB_FILE, 

The processing in this flowchart starts in step S200 
5 with the CPU 28 generating the Def aultPlaylist and the 
TrackManager . In step S201, the CPU 28 initializes the 
variable #z (z^l) . In step S202, the CPU 28 generates the 
AOB_FILE#z and stores it in the data region of the flash 
memory card 31. At this point, the filename, filename 

10 extension, and first cluster number for the AOB_FILE#z will 
be set in a directory entry in the SD__Audio Directory in 
the data region. After this, in step S203, the CPU 28 
generates TKI#z and stores it in the TrackManager. In step 
S204, the CPU 28 generates the DPL__TK__SRP#w and stores it 

15 in the Def ault__Playlist__Inf ormation • After this, in step 
S205 the CPU 28 initializes the variable#y (#y^l) and in 
step S206, the CPU 28 initializes the Frame_Number and 
Data__Size (Frame_Number'^0, Data__Size^O) . 

In step S207, the CPU 28 judges whether the input of 

20 the audio data transport stream that should be written in 
the AOB_FILE# has ended • When the input of an audio data 
transport stream that has been encoded by the AAC encoder 
25 and encrypted by the scrambling unit 2 6 into the RAM 
22 continues and it is necessary to continue the writing 

25 of cluster data, the CPU 28 gives the judgement "No" in 
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step S207 and the processing advances to step S209. 

In step S209, the CPU judges whether the amount of AAC 
audio data that has accumulated in the RAM 22 is at least 
equal to the cluster size. If so, the CPU 28 gives the 
5 judgement "Yes" and the processing advances to step S210 
where an amount of AAC audio data equal to the cluster size 
is written into the flash memory card 31. The processing 
then advances to step S211. 

When sufficient AAC audio data has not accumulated 
10 in theRAM22, stepS210 is skipped and the processing advances 
to step S211. In step S211, the CPU increments the 
Frame_Number (Frame_Number^Frame__Number+l ) and increases 
the value of the variable Data_Size by the data size of 
the AOB_FRAME. 

15 After this updating, in step S212 the CPU 28 judges 

whether the value of Frame__Number has reached the number 
of frames that is set in "FNs_Middle__TMSRTE" , the value 
of "FNs_Middle_TMSRTE" is set in accordance with the 
sampling frequency used when encoding the audio data 

20 transport stream. When the value of Frame__Number has 
reached the number of frames set in "FNs_Middle_TMSRTE", 
the CPU 28 gives the judgement "Yes" in step S212, If not, 
the CPU 28 gives the judgement "No" and the processing returns 
to step S207. The processing in steps S207 to S212 is 

25 therefore repeated until the judgement "Yes" is given in 
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either step S207 or in step S212. 

When the variable Frame_Number reaches the value of 
"FNs_Micidle_TMSRTE", the CPU 28 gives the judgement "Yes" 
in step S212 and the processing advances from step S212 
5 to step S213 where Data__Size is stored in the TKTMSRT of 
TKI#z as the TMSRT__entry#y for the AOB_ELEMENT#y . In step 
S214, the CPU 28 increments the variable#y (#y^#y+l) before 
checking in step S215 whether the variable#y has reached 
"252". 

10 The value "252" is used since this is the maximum_number 

of AOB_ELEMENTs that can be stored in a single AOB. If the 
variable #y is below 252, the processing advances to step 
S216, where the CPU 28 judges whether a silence of a 
predetermined length is present in the encoded audio, which 

15 is to say that the audio data has reached a gap present 
between tracks . When no such continuous silence is present, 
the processing composed of steps S206 to S215 is repeated. 
When the variable#y has reached the value 252, or a silence 
of a predetermined length is present in the encoded audio, 

20 the judgement "Yes" is given in one of steps S215 and S216 
and the processing advances to step S217 where the variable#z 
is incremented (#z^#z+l) . 

After this, the processing in steps S202 to S216 is 
repeated for the incremented variable#z . By repeating this 

25 processing, the CPU 28 can have AOBs including a plurality 
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of AOB_ELEMENTs recorded one after the other into the flash 
memory card 31. 

When the transfer of an audio data transport stream 
by the AAC encoder 25, the scrambling unit 26, and the modem 
5 apparatus 27 is complete, this means that the input of the 
audio data transport stream to be written into the A0B_FILE#2 
will also be complete, so that the judgement "Yes" is given 
in step S207 and the processing advances to step S208. In 
step S208, the CPU 28 stores the value of the variable 

10 Data_Size in the TKTMSRT of the TKI#z as the TMSRT__Entry#y 
for the AOB_ELEMENT#y • After storing the audio data 
accumulated in the RAM 22 in the AOB file corresponding 
to the AOB#z, the processing in this flowchart ends. 

The above processing results in an encrypted audio data 

15 transport stream being stored in the flash memory card 31, 
The following procedure is then used to store the FileKey 
required for decrypting this encrypted audio data transport 
stream in the authentication region. 

When the audio data transport stream has been inputted 

20 via input route RTl, the AOB file(s) , the file storing the 
TKMG, the file storing the PLMG, and the encryption key 
storing file storing a different FileKey for each AOB are 
sent to the recording apparatus by a provider of the 
electronicmusic distribution service . The CPU 28 receives 

25 these files and writes the AOB file(s), the file storing 
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the TKMG, and the file storing the PLMG into the user region 
of the flash memory card 31* On the other hand, the CPU 
28 writes only the encryption key storing file storing a 
different FileKey for each AOB into the authentication 
5 region. 

When the audio is inputted via the input route RT2 or 
RT3, the CPU 2 8 generates a different FileKey every time 
the encoding of a new AOB commences and sets the generated 
key in the scrambling unit 26. In addition to being used 
10 by the scrambling unit 2 6 to encrypt the present AOB, this 
FileKey is stored following the FileKey Entry in the 
encryption key storing file present in the authentication 
region . 

With the present embodiment describes above, the files 
15 storing AOBs are encrypted using different encryption keys, 
so that if the encryption key used to encrypt one file is 
decoded and exposed, the exposed encryption key can only 
be used to decrypt a file storing one AOB, with such exposure 
having no effect on other AOBs that are stored in other 
20 files . This minimizes the damage caused when one encryption 
key is exposed. 

Note that while the above description focuses on an 
example system that is thought to be the most effective 
embodiment of the present invention, the invention is not 
25 limited to this system. Various modifications are possible 
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within the scope of the invention, with examples of the 
such being given as (a) to (e) below. 

(a) The above embodiment describes a semiconductor 
memory (flash memory card) as the recording medium used, 

5 though the present invention can be applied to other media 
including optical discs, such as DVD-RAM, or a hard disk. 

(b) In the above embodiment, the audio data was 
described as being in AAC format, though the present 
invention can also be applied to audio data in another format 

10 such as MPS (MPEG 1 Audio Layer 3 ) , Dolby-AC3, or DTS (Digital 
Theater System) . 

(c) While the file storing the TKMG and the file storing 
the PLMG were described as being received from the provider 
of the electronic music distribution service in a complete 

15 form, the main information used to create the TKMG and PLMG 
can be transmitted together with the encryption key storing 
file that stores a different encryption key for each AOB. 
The recording apparatus may then process this information 
to obtain the TKMG and PLMG which it then records in the 

20 flash memory card. 

(d) For ease of explanation, the recording apparatus 
and playback apparatus were described as being separate 
devices, though a portable playback apparatus can be 
equipped with the functioning of the recording apparatus 

25 and a recording apparatus in the form of a personal computer 
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can be equipped with the functions of the playback apparatus . 
Aside from the portable playback apparatus and personal 
computer recording apparatus, the functions of the playback 
apparatus and recording apparatus can also be provided to 
5 a communication device that is capable of downloading 
content from a network. 

As one example, a mobile telephone capable of Internet 
access may be provided with the functions of the playback 
apparatus and recording apparatus described in the above 

10 embodiment. This mobile telephone may store contents 
downloaded via a wireless network in the flash memory card 
31 in the same way as in the above embodiment. Also, while 
the recording apparatus described in the above embodiment 
is provided with the modem apparatus 2 7 for connecting to 

15 the Internet, any other device capable of connecting to 
the Internet, such as a terminal adapter for an ISDN line, 
may be provided instead. 

(e) The procedures shown in the flowcharts shown in 
FIGS. 55 to 58, FIG. 60, FIG. 63 to FIG. 65, and FIG. 68 

20 can be achieved by executable programs that may be 

distributed and sold having been recorded on a recording 
medium. This recording medium may be an IC card, an optical 
disc, a floppy disk, or the like, with the programs recorded 
on the recording medium being used having first been 

25 installed into standard computer hardware. By performing 
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processing in accordance with such installed programs, 
standard computer hardware can perform the same functioning 
as the playback apparatus and recording apparatus described 
in the above embodiment. 

(f ) While the above embodiment describes the case where 
a plurality of AOBs and a plurality of FileKeys are stored 
on the flash memory card 31, only one AOB and one FileKey 
need be stored. Also, it is not essential for the AOBs to 
be encrypted, so that AOBs may be stored on the flash memory 
card 31 in ACC format. 

SECOND EMBODIMENT 

{69-1} Overall Coioposition of the PlaylistManager in the 
Second Embodiment 

This second embodiment relates to an improvement in 
the semiconductor memory card of the first embodiment that 
allows a playback apparatus to resume playback without 
repeating tracks that were previouslyplayed. FIG. 69 shows 
the internal composition of the PlaylistManager and 
TrackManager in this second embodiment. The 
PlaylistManager and TrackManager in this second embodiment 
differ from those shown in FIG. 17 in that the composition 
of the PlaylistManager_Information (PLMGI) is shown clearly 
in FIG, 69, unlike in FIG. 17. 

Of particular importance in the PLMGI is the 
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PLMG_RSM_PL. This shows the playback resume position, and 
is stored on the semiconductor memory card to enable a 
playback apparatus to resume playback of the content without 
repeatedly playing back the same data, 

{70-1} Detailed Composition of the PlaylistManager 
Infonaation 

FIG. 70 shows the detailed composition of the 
PlaylistManager__Information. As shown in the drawing, the 
PLMGI has a PLMG_ID field that occupies the 0th and first 
bytes, a reserved field that occupies the second and third 
bytes, an SDA_ID field that occupies the fourth to eleventh 
bytes, a VERN field that occupies the twelfth and thirteenth 
bytes, a PLMG__PL__Ns field that occupies the fourteenth and 
fifteenth bytes, a PLMG_AP__PL field that occupies the 
sixteenth to nineteenth bytes, a PLMG_RSM_PL field that 
occupies the twentieth to twenty-seventh bytes, a 
PLMG__APP__ATR field that occupies the twenty-eighth and 
twenty-ninth bytes, a PLMG_FCA field that occupies the 
thirtieth and thirty-first bytes, a TKI_Ns field that 
occupies the thirty-second and thirty-third bytes, and a 
reserved field that occupies the thirty- fourth and 
thirty-fifth bytes . Of these fields in the PlaylistManager, 
the PLMG__AP_PL and PLMG__RSM_PL are of most importance in 
this second embodiment. 
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{ 70-2 } Information aside from the PLMG_AP_PL and PIiM6_RSM_PL 

The following first describes the fields in the 
PlaylistManager aside from the PLMG__AP_PL and PLMG_RSM_PL, 

The PLMG__ID is set at "Al" (a character string set 
according to IS064 6 Standard) to show that the present 
information is a PLMGI • 

The SDA_ID is set at "SD-AUDIO" (a character string 
set according to IS064 6 Standard) to show that the present 
PlaylistManager is data in accordance with the SD-AUDIO 
specification . 

A version number for the SD-AUDIO specification used 
is set in the VERN field. The broken line h71 in FIG. 70 
shows the bit composition of the version number. The field 
composed of bits b? to bO is used to store the version number. 
When^ for example, the version number of the present 
PlaylistManager is "Version 0.9", "09h" is written in this 
field, and when the version number is "Version 1.0", "lOh" 
is written in this field. The field composed of bits bl5 
to b8 is reserved for future use. 

The number of playlists managed by the PLMG, which 
is to say, the number of playlists recorded on the present 
flash memory card is written in the PLMG_PL__Ns field. 

The application category ID, which shows the category 
of the application recorded on the present flash memory 
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card, is written in the PLMG__APP__ATR field. When, as in 
the first embodiment, the application stored on the present 
flash memory card is music, the value "Olh" is written in 
this field. 

5 When the application recorded on the present flash 

memory card is karaoke software, the value "02h" is written 
in this field, when the application is presentation data, 
the value "03h" is written in this field, and when the 
application is an audiobook, the value "04h" is written 

10 in this field. 

When the application category ID is "02h", the audio 
data is recorded on the present flash memory card as karaoke 
data, so that the right channel is used for the backing 
track and the left channel is used for the vocals. When 

15 audio data is recorded in this way, a playback apparatus 
can play back a karaoke backing track by playing back the 
audio data for the right channel on both the left and right 
channels . 

The PLMG_FCA field is reserved for future use. 
20 An integer showing the number of TKIs, like that in 

the first embodiment, is written in the TKI__Ns field. This 
value is given in the range from "1" to "999". 

This completes the explanation of the fields in the 
PlaylistManager aside from the PLMG_AP___PL and PLMG__RSM_PL . 

25 
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{70-3} PIMG_AP_PI. 

The PLMG__AP__PL shows the number of a playlist that 
is to be automatically read and the number of the first 
track to be automatically played back in that playlist when 
5 the present flash memory card is loaded into a playback 
apparatus and the playback apparatus activated. The 
broken line h72 in FIG. 70 shows the bit composition of 
the four bytes of the PLMG_AP_PL. The field between bit 
b31 and b2 6 and the field between bl5 and b8 are reserved 

10 for future use. Bits b7 to bO form a Playlist Number field 
in which a number of the playlist to be automatically read 
is given in the range of "1" to "99" (in decimal) . The number 
written in this field is the number of a Playlist__Inf ormation 
(PLI) as described in the first embodiment. To indicate 

15 the Default__Playlist_Inf ormation, the number "0" is 
written . 

Bits b25 to bl6 form a Track Number field in which 
a number of the track to be automatically played back out 
of the plurality of tracks specified by the playlist is 
20 given . The number written in this field is the Track_Number 
as described in the first embodiment. The values in the 
fields of the PL]yiG_AP_PL can be freely set by the user, 
and must be set at "0" when the PLMG_AP_PL is not used. 

25 
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{70-4} PLMG_RSM_PL 

When playback has already been performed for one or 
more AOB files recorded on the flash memory card, the 
PLMG__RSM__PL will include a Playlist Number showing the 
5 playlist that was used for the previous playback of data 
on the flash memory card, a Track Number showing the number 
of the last track to be played back according to this playlist, 
and a Playback Time showing at what point the playback stopped 
in the track indicated by the Track Number. 

10 In FIG. 70, the broken line h73 shows the bit 

composition of the PLMG^RSM^PL . The bit composition of bit 
number b31 to bit number bO is the same as the PLMG_AP__PL. 
The number of the playlist that was used for the preceding 
playback is written as a value in the range from "0" to 

15 "99" in the Playlist Number field that occupies the region 
from bit number b7 to bit number bO. The number of the last 
track to be played back out of the various tracks specified 
by this playlist is written in the Track Number field that 
occupies the region from bit number b25 to bit number bl6. 

20 Unlike the bit composition of the PLMG_AP_PL, the 

region frombit number b32 tobit number b63 of the PLMG_RSM_PL 
forms a Playback_Time field . The time at which the preceding 
playback of the track indicated by the Track Number was 
stopped is written in this field to millisecond accuracy. 

25 Note that when PLMG__RSM_PL is not used by the user, the 
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value "0" must be set in all fields of the PLMG_RSM_PL. 

{70"4_71} Setting of the PIiMG_RSM_PL when the Flash Memory 
Card is Transferred Between Playback Apparatuses 

5 The following describes how the PLMG_AP_PL and 

PLMG_RSM_PL are set when the flash memory card of this second 
embodiment is transferred between playback apparatuses. 
FIG. 71 shows how the PLMG_AP_PL and PLMG__RSM_PL are set 
when the flash memory card of this second embodiment is 

10 transferred between playback apparatuses. 

InFIG. 71, the f lashmemory card is transf erredbetween 
a plurality of playback apparatuses that are composed of 
a standard personal computer, a portable playback apparatus 
and an in-car playback apparatus. Note that each of these 

15 playback apparatuses is equipped with the functions of the 
playback apparatus and recording apparatus described in 
the first embodiment. 

The present explanation describes a flash memory card 
that stores AOB files composing TrackA to TrackE, in the 

20 same way as in FIG, 16. 

Assume that the flash memory card of this second 
embodiment is first loaded into the personal computer 200 
which records the presentation data and navigation data 
described in the first embodiment. Assume that after this, 

25 the personal computer 200 sets the PLMG_AP_PL with the 
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Playlist__Number "0" indicating the 

Def ault__Playlist_Inf ormation and the Track__Number "3" 
indicating TrackC* In this example, the user has the AOB 
files on the flash memory card played back in the order 
5 TrackA, TrackB, TrackC and stops the playback at a point 
3min31secs into the playback of TrackC whose playback period 
is 5.5 minutes. In this case, the personal computer 200 
writes the Playlist_Number "0" indicating the 
Def ault_Playlist_Inf ormation and the Track__Number "3" 

10 indicating TrackC into the PLMG_RSM_PL field. In addition, 
the personal computer 200 also writes the value 
"00:03:31:000" showing the point where playback was stopped 
for TrackC into the Playback_Time field in the PLMG_RSM_PL. 
After this, the user removes the flash memory card from 

15 the personal computer 200 and, as shown by the arrow my71, 
loads it into the portable playback apparatus 100. 

In the first embodiment, the playback apparatus (the 
portable playback apparatus 100) starts the playback with 
the first AOB__FRAME in TrackA that is specified by the 

20 Def ault__Playlist__Inf ormation . In this second embodiment, 
however, the PLMG_AP_PL and PLMG_RSM__PL are provided in 
the PlaylistManager__Inf ormation, so that the playback 
apparatus can start the playback from any AOB__FRAME in 
accordance with the content of this information. 

25 Since the personal computer 200 set the value "0" in 
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the Playlist__Number to indicate the 

Def ault__Playlist_Inf ormation, the value "3" in the 
Track__Nuinber to indicate TrackC and "00:03:31,000" in the 
Playback_Tiine, the portable playback apparatus 100 can know 
5 that the playback has already been performed up to a point 
3 min 31 sees into TrackC in the 
Def ault_Playlist_Inf ormation and that playback should be 
performed from a point 3 minutes and 31.001 seconds into 
TrackC . 

10 Assume that the user puts in the earphones attached 

to the portable playback apparatus 100 and leaves the house 
after the playback of TrackC has commenced. 

In the present example, the user listens to the end 
part of TrackC and then a first part of TrackD, stopping 

15 the playback at a point 10 minutes and 30 seconds into the 
playback of TrackD. In this case, the portable playback 
apparatus 10 0 updates the content of the PLMG_RSM_PL by 
writing "0" in the Playlist_Number to indicate the 
Def ault__Playlist_Inf ormation, "4" in the Track__Number to 

20 indicate TrackD, and "00:10:30.000" in the Playback_Time 
to indicate that playback was stopped at a point 10 minutes 
and 30 seconds into the playback of TrackD. On the other 
hand, the content of the PLMG_AP__PL is not rewritten, so 
that the Playlist_Number stays at "0" to indicate the 

25 Def ault_Playlist_Inf ormation and the Track_Number remains 
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at "3" to indicate TrackC. 

After this, assume that the user removes the flash 
memory card from the portable playback apparatus 100 and, 
as shown by the arrow my72 in FIG. 71, loads it into the 
5 in-car player 300. 

Since the portable playback apparatus 100 set the value 
"0" in the Playlist__Number to indicate the 
Def ault__Playlist_Inf ormation, the value "4" in the 
Track_Number to indicate TrackD and "00:10:30,000" in the 

10 Playback_Time, the in-car player 300 can know that the 
playback has already been performed up to a point 10 min 
30 sees into TrackD in the Def ault_Playlist_Inf ormation 
and that playback should be performed from a point 10 minutes 
and 30.001 seconds into TrackD. 

15 The playback of TrackD commences from this point and 

continues for 9 minutes and 30 seconds before the user stops 
the playback once again. Since part of TrackD remains, the 
Playlist__Number and Track__Number in the PLMG__RSM_PL are 
left unchanged, and only the Playback_Time is updated using 

20 the value "00:20:00.000". 

As described above, when the flash memory card is 
removed from the personal computer 200 and loaded into the 
portable playback apparatus 100, playback commences from 
a point immediately following the point where playback by 

25 the personal computer 200 was stopped. 
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In the same way, when the flash memory card is removed 
from the portable playback apparatus 100 and loaded into 
the in-car player 300, playback commences from a point 
immediately following the point where playback by the 
5 portable playback apparatus 100 was stopped. This means 
that the flash memory card can be transferred from the 
personal computer 200 to the portable playback apparatus 
100 and then to the in-car player 300 without the same data 
being played back twice . 

10 

{70-5} Updating of the PLMG_AP_PL and PLM6_RSM_PL When the 
TKI is Edited 

No further explanation of the PLMG__AP_PL and 
PLMG_RSM_PL will be given. Instead, the following will 

15 describe how the content of the PLMG_AP_PL and PLMG__RSM_PL 
are updated for four editing operations described in the 
first embodiment . These are easel where a track is deleted, 
case3 where two tracks are combined, case4 where a track 
is divided into two, and caseS where the playback order 

20 of tracks is rearranged. 

When in easel, the track specified by the PLMG_AP_PL 
and PLMG_RSM_PL is deleted, the Track_Number given in the 
PLMG_AP__PL and PLMG__RSM__PL in the PlaylistManager is set 
so as to indicate the track that follows the deleted track 

25 in the indicated playlist. The Playback_Time in the 
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PLMG_RSM_PL is also set at "00:00:00.000" to indicate the 
start of this following track. 

When in case3, the track specified by the PLMG__AP_PL 
and PLMG_RSM_PL is combined with another track, the 
5 Track_Nuinber given in the PLMG_AP_PL and PLMG_RSM_PL in 
the PlaylistManager is set so as to indicate the position 
of the combined track in the indicated playlist. 

When in case4, the track specified by the PLMG_AP_PL 
and PLMG_RSM_PL is divided, the Track_Number given in the 

10 PLMG__AP_PL and PLMG__RSM_PL in the PlaylistManager is set 
so as to indicate the position of the former part or latter 
part of the divided track in the indicated playlist. The 
Playback_Time is compared with the division boundary and 
when the Playback_Time is before the division boundary, 

15 the Track__Number of the track corresponding to the former 
part of the divided track is set in the PLMG_RSM_PL. When 
the Playback_Time is after the division boundary, the 
Track_Number of the track corresponding to the latter part 
of the divided track is set in the PLMG___RSM_PL . 

20 When in case5 the position of the track indicated by 

the PLMG_AP_PL and PLMG_RSM_PL in the indicated playlist 
is changed, the Track_Number given in the PLMG_AP_PL and 
PLMG__RSiyi_PL in the PlaylistManager is set so as to indicate 
the new position of the track in the indicated playlist. 

25 While the above explanation states that the PLMG_AP_PL 
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and PLMG_RSM_PL are updated when tracks are edited^ the 
settings of the PLMG_AP_PL and PLMG_RSM_PL may simply be 
cleared when track editing is performed, 

5 {72-1} Setting of How the PIiMG_RSM_PL , PLM6_AP_PL are Used 

The following describes the playback apparatus of this 
second embodiment. This playback apparatus has three main 
differences from the playback apparatus described in the 
first embodiment. 

10 A first difference is the playback apparatus receives 

the setting of the PLMG_AP_PL and the initial settings from 
the user. FIG. 72 shows the menu screen used for receiving 
a user input of the PLMG__AP_PL and the initial settings. 
As shown in FIG. 72, by selecting one of the character 

15 strings "resume playback from previous position" or "start 
with favorite track", the user can have the playback 
apparatus refer to either the PLMG_AP__PL or PLMG_RSM_PL 
when a flash memory card is loaded. In this example, the 
user's "favorite track" is the track specified by the 

20 Playlist_Number and Track_Number given in the PLMG___AP_PL . 

When the user selects one of these character strings, 
the playback apparatus sets an appropriate flag. This flag 
(called the "activation flag") shows whether the playback 
should start from the Playlist__Number and Track_Number given 

25 in the PLMG AP_PL or from the Playlist_Number , Track_Number 
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and Playback_Time given in the PLMG_RSM_PL. When the user 
selects "resume playback from previous position", the 
activation flag is set at "on", so that when a flash memory 
card is loaded, the playback apparatus refers to the 
5 PLMG_RSM_PL and starts playing back data from the point 
where playback was previously stopped. When the user 
selects "start with favorite track", the activation flag 
is set at "off", so that when a flash memory card is loaded, 
the playback apparatus starts the playback with the track 

10 indicated in the PLMG_AP_PL. 

The menu screen shown in FIG. 72 also allows the user 
to set his/her favorite track. When the user performs an 
input operation using a key panel, the PLMG__AP_PL on the 
flash memory card is written so as to show the indicated 

15 playlist and track. Note that the activation flag may be 
set in other ways, such as by a dip switch or a push-button 
switch provided on the playback apparatus. 

{56_57_58-l} Updating the PIiMG_RSM_PL 

20 A second difference with the first embodiment is that 

when the user presses the "Stop" key, the playback apparatus 
of the second embodiment updates the setting of the 
PLMG_RSM_PL. In the first embodiment, a pressing of the 
"Stop" key in any of the flowcharts in FIGS. 56, 57 and 

25 58 results in the judgement "Yes" being given in step S31, 



163 



step S42, or step S54 and the processing in that flowchart 
ending • 

In the second embodiment, however, the playback 
apparatus will then set values in the PLMG_RSM__PL. In more 
5 detail, the playback apparatus specifies the 
Playlist__Number of the playlist currently being used for 
playback and the Track__Number corresponding to the AOB 
currently being played back and writes these into the 
PLMG_RSM__PL • The playback apparatus also refers to the 

10 value of the variable play_time (that was described in the 
first embodiment) at the point when playback was stopped 
and sets this value in the PLMG_RSM_PL as the Playback Time. 

In addition to when the "Stop" key is pressed, the 
playback apparatus may also update the settings in the 

15 PLMG_RSM_PL when the user presses the "Pause" key. The 
playback apparatus may also update the settings of the 
Playlist___Number, Track_Number and Playback__Time in the 
PL]yiG_RSM_PL when the remaining power in the batteries is 
low. As a result, valid information can be set in the 

20 PLMG__RSM_PL for the case where playback stops not because 
the user has pressed the "Stop" key but because the batteries 
of the playback apparatus have run out. 

{73-1} Playback Position Specifying Procedure 

25 The following describes the third difference with the 
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first einbodiment . In the first embodiment, AOB files are 
played back in the order in which they are specified by 
a playlist. In this second embodiment, however, playback 
is performed starting from the playback position determined 
5 in accordance with the procedure shown in FIG. 73. The 
following describes the playback position determining 
procedure based on the PLMG_AP__PL and PLMG_RSM_PL. This 
description refers to the flowchart in FIG. 73. 

Once the processing in this flowchart is activated, 

10 in step S301 the CPU 10 refers to the activation flag that 
was set using the menu screen in FIG. 72 and determines 
which of the PLMG_AP_PL and PLMG_RSM_PL should be referred 
to when a flash memory card is loaded. 

When the activation flag indicates the PLMG__AP_PL, 

15 the processing advances from step S301 to step S302. In 
step S302, the CPU 10 refers to the PLMG_AP_PL and specifies 
the TKI of the track specified by the Track__Number in the 
playlist specified by the Playlist_Number as the TKI#z that 
was described in the first embodiment. The CPU 10 then 

20 Starts playing back the AOB f ile#z that corresponds to TKI#z . 

When the activation flag indicates that priority 
should be given to the PLMG_RSM__PL, the processing advances 
from step S301 to step S303. In step S303, the CPU 10 reads 
the PLMG_RSM_PL from the PlaylistManager___Inf ormation and 

25 in step S304 the CPU 10 judges whether the Playlist_Number, 
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Track__Nuinber^ and Playback__Time written in the PLMG_RSM_PL 
are valid. 

When the PLMG_RSM__PL was not properly set the last 
time playback stopped, or when there is an error during 
5 a read of clusters indicated by the PLMG_RSM__PL, the CPU 
10 will judge that the PLMG_RSM_PL is invalid. The 
processing will then proceed from step S304 to step S302 
where the CPU 10 starts playback based on the PLMG__AP_PL. 
When the Playlist___Nu3nber , Track_Number, and 

10 Playback_Time in the PLMG_RSM_PL are valid, the processing 
proceeds from step S304 to step S305 where the CPU 10 judges 
whether the value of Playback__Time given in the PLMG_RSM_PL 
is the same as the playback period (TKI_PB__TM) of the track 
indicated by the Track__Number written in the PLMG__RSM_PL • 

15 If these two values are not equal, part of the track indicated 
by the Track_Number is yet to be played back, so that in 
step S306 the CPU specifies the TKI indicated by the 
Track_Number in the PLMG_RSM__PL as TKI#z and in step S307 
the CPU 10 specifies the AOB_FRAME#x and AOB_ELEMENT#y from 

20 which playback should start within an AOB file corresponding 
to this TKI, based on the Playback_Time given in the 
PLMG__RSM_PL • 

The procedure for specifying the AOB_ELEMENT#y and 
AOB_FRA]y[E#x that correspond to any particular playback start 
25 time within a track was described in the first embodiment 
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using Equations 1 to 3. The CPU 10 uses these equations 
to calculate the AOB___ELEMENT#y and AOB__FRAME#x and then 
in step S308 starts the playback from the AOB__FRAME#x in 
the AOB___ELEMENT#Y in the AOB file#z. 
5 When the value of Playback_Tiine is equal to the value 

of TKI_PB__TM, the judgement "Yes" is given in step S305 
and the processing advances to step S309. The CPU 10 then 
judges whether the Track__Number in the PLMG_RSM_PL is equal 
to the TKI_Ns given in the PlaylistManager . If not, this 

10 means that at least one track is yet to be played back in 
the playlist specified by the Playlist_Number, so that the 
processing advances from step S309 to step S311» In step 
S311, the TKI following the TKI specif iedby the Track_Number 
in the PLMG_RSM__PL is specified as TKI#z and in step S312 

15 the CPU 10 starts the playback of AOBs from the start of 
the AOB file#z that corresponds to TKI#z. 

When the TKI_PB_TM is equal to the Playback_Time and 
the Track_Number given in the PLMG_RSM__PL is equal to the 
TKI_Ns, it can be assumed that the playlist indicated by 

20 the Playlist_Number in the PLMG_RSM_PL will have been played 
back in its entirety, so that the playback apparatus will 
then receive a user input of the next playlist to be played 
back. 

With the present embodiment, PLMG_RSM_PL is recorded 
25 on the semiconductor memory card as the playback resume 
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position. This information shows how far the previous 
playback of the semiconductor memory card proceeded^ so 
that when the semiconductor memory card is removed from 
a playback apparatus and loaded into another playback 
5 apparatus, this second playback apparatus can commence 
playback at a point immediately following the point where 
playback by the first playback apparatus ended. 

As a result, when the user listens to a part of a music 
album composed of TrackA to TrackE on a first playback 

10 apparatus, stops the playback, and then has the album played 
back on a different playback apparatus, this second playback 
apparatus can refer to the PLMG_RSM_PL showing the point 
where the previous playback stopped and so know what part 
of the album has already been played back to millisecond 

15 accuracy. The playback apparatus can therefore resume the 
playback from a point immediately following the point where 
playback was stopped. This means that the user does not 
have to listen to the same tracks , even when the semiconductor 
memory card is transferred from one playback apparatus to 

20 another. 

THIRD EMBODIMENT 

{74-1} DPLI_RSM_PL, PLI_RSM_PIi 

In this third embodiment, the DPLI and each PLI are 
25 each provided with their own playback resume information, 
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DPLI_RSM_PL or PLI_RSM__PL , to show at what point the previous 
playback of that playlist ended. FIG. 74 shows the 
Def ault__Playlist_Inf ormation that has a DPLI_RSM_PL in the 
DPLGI and a PLI that has a PLI__RSM_PL in the PLGI . 
5 The DPLI__RSM_PL (PLI_RSM_PL) only include a 

Track__Nuinber and Playback___Time, and so differs from the 
PLMG_RSM_PL in that a Playlist_Number is unnecessary. As 
another difference, when all of the tracks in the playback 
order indicated by the DPLI or a PLI have been completely 

10 played back, the value "FF" is set in the Track_Number in 
the DPLI_RSM_PL (PLI__RSM_PL) to show that the playlist was 
completely played back. 

The following describes the playback apparatus of the 
third embodiment . 

15 When the playback of the tracks specified in the 

playback order of a PLI is stopped midway, the playback 
apparatus writes the PlayList_Number of that PLI, the 
Track___N umber of the current track, and the Playback_Time 
into the PLMG_RSM_PL in the same way as in the second 

20 embodiment. As a difference, however, the playback 
apparatus also writes the Track_Number and the Playback_Time 
into the PLI_RSM_PL corresponding to that Playlist_Number . 

In the same way as in the first embodiment, a user 
can indicate a playlist to be played back. In this third 

25 embodiment, however, the playback apparatus will refer to 
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the PLI__RSM_PL of the PLI for the indicated playlist. When 
no values are given in the Track__Nuinber and Playback_Time 
in the PLI_RSM_PL of that playlist^ the playback apparatus 
starts the playback from the start of the first track in 
5 the playback order given in the PLI . Conversely, when values 
are given in the Track_Number and Playback_Tiine in that 
PLI_RSM_PL, the playback apparatus plays back the tracks 
in the playback order given in that PLI starting from the 
position indicated by the Track_Number and Playback_Time . 

10 

{74-2_75_76} 

FIG. 75 shows how the DPLI__RSM_PL of the DPLI and the 
PLI_RSM_PLs of several PLIs are set. FIG. 7 6 shows a track 
sequence composed of the playback order specified by the 
15 playlist shown in FIG. 41 that was referred to in the first 
embodiment . 

Track sequences are separately specified by the DLPI, 
PLI#1, and PLI#2, with the playback ranges (1) to (3) in 
FIG. 76 showing the parts of these track sequences that 
20 have already been played back. 

The following describes where the playback will 
commence when one of the DLPI, PLI#1, or PLI#2 is indicated 
for playback with the playback ranges (1) to (3) having 
already been played back. 

25 
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{74-3_75_76} 

Playback of the track sequence indicated by the DPLI 
was previously performed up to a point midway through TrackC, 
so that in the DPLI__RSM_PL in the DPLI, "TrackC" and 
5 "00:03:31*00004" are set in the Track_Number and 
Playback_Time to show the playback resume position (4) at 
the end of the playback range (1) - 

Reproduction of the track sequence indicated by PLI#1 
was previously performed up to the end, so that in the 
10 PLI__RSM_PL of PLI#1, "FF" is set in the Track_Number . 

Reproduction of the track sequence indicated by PLI#2 
was previously performed up to a point midway through TrackA, 
so that in the PLI_RSM_PL of PLI#2, "TrackA" and 
"00:01:11.00000" are set in the Track_Number and 
15 Playback_Time to show the playback resume position (5) at 
the end of the playback range (2) . 

Since PLI#3 is yet to be indicated and its track 
sequence has not been played back, the value "00" is set 
in the Track_Number in the PLI__RSM__PL of PLI#3. 
20 As the PLI_RSM__PL (DPLI__RSiyi_PL) of each PLI (and the 

DPLI) are set as shown in FIG. 75, if the user indicates 
the DPLI after indicating PLI#1, the playback of the track 
sequence indicated by the DPLI will be resumed from the 
playback resume position (4) immediately after the playback 
25 range (1) . 
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If the user indicates PLI#2 once the track sequence 
indicated by the DPLI has been completely played back, the 
playback of the track sequence indicated by PLI#2 will be 
- resumed from the the playback resume position (5) 
5 immediately after the playback range (2) . 

With this embodiment, when a playlist is indicated 
for playback by a user operation, the playback apparatus 
will refer to the PLI___RSM_PL (DPLI_RSM_PL) for the indicated 
. playlist and will resume the playback of the track sequence 

10 specified by that playlist in accordance with the 
Track_Number and Playback_Time given in that PLI_RSM_PL 
(DPLI_RSM_PL) . This means that playback can be resumed for 
any of the playlists without repeating tracks that have 
been previously played back. 

15 Note that since the resumption of playback for every 

playlist is performed in this embodiment according to the 
Track_Number and Playback_Time in the PLI__RSM_PL 
(DPLI__RSM_PL) , it is preferable for the user indication 
of the playlist to be made via a menu like that shown in 

20 FIG. 77 instead of via the menu of the first embodiment 
shown in FIG. 49 that merely gives a list of the playlists. 
FIG. 77 shows an example menu that displays the playlists 
together with the settings of the PLI_RSM_PL for each 
playlist for the case where the playback ranges (1) to (3) 

25 shown in FIG. 7 6 have already been played back. PLIs that 
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have not had their track sequences playedback in its entirety 
are displayed with a track number showing the Track_Number 
in the PLI_RSM_PL and a playback time based on the value 
of the Playback__Time in the PLI_RSM__PL. Conversely, PLIs 
5 that have had their track sequences played back in their 
entirety have the value "FF" set in the Track_Number in 
the PLI_RSM_PL and so are displayed with an indication 
showing that playback is complete. As a result, this menu 
tells the user how much of each playlist has been played 
10 back, so that the user can know which playlists have been 
entirely played back and which playlists have only been 
partially played back. 

FOURTH EMBODIMENT 

15 While music applications are stored on the f lashmemory 

card 31 in the first to third embodiments, the present 
embodiment relates to an improvement in the storage of 
short-lived applications. Here a "short-lived 

application" refers to any application, such as news, an 

20 audio magazine, a recording of a speech etc., that only 
needs to be listened to once, and so differs from music 
applications that are repeatedly listened to. As 
conventional examples of short-lived applications, 
magazines tend to be published weekly or monthly while news 

25 tends to be published every day. 
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When a recording apparatus downloads a short-lived 
application via a network, the recording apparatus records 
the audio data composing the short-lived application onto 
the flash memory card 31 as AOBs, generates a plurality 
5 of TKIs for the AOBs, and stores these TKIs on the flash 
memory card 31. The recording apparatus also generates 
Playlist__Inf ormation specifying' the TKI(s) for this 
short-lived application and records the PLI onto the flash 
memory card 31. 

10 The following describes the improvements in the DPLI, 

PLIs and TKIs made in this fourth embodiment. In the second 
embodiment, the PLI__APP_ATR is provided in the 
PlaylistManager as information showing the attributes of 
an application. In the fourth embodiment, PLI_APP_ATR and 

15 TKI_APP___ATR are also provided as the application attributes 
in the DPLGI, PLGI, and TKGI . FIG. 78 shows the data format 
of the DPLGI, PLGI, and TKGI in this fourth embodiment. 

Like the "PLMG_APP_ATR" in the second embodiment, the 
PLI_APP_ATR in a PLGI includes an application category ID 

20 showing the category to which the PLI belongs . When the 
genre of an application corresponding to a PLI is music 
like in the first embodiment, the value "Olh" is set in 
this field. 

In the same way, the value "02h" is set in this field 
25 when the application corresponding to a PLI is a karaoke 
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software, the value "03h" when the application is 
presentation data, and the value "04h" when the application 
is an audiobook. Other values may also be used to indicate 
other types of application. In the PLI for a short-lived 
5 application, the PLI__APP_ATR in the PLGI is set at "04h" 
to indicate an audiobook, 

A recording apparatus generates a PLI for a short-lived 
application in this way and stores this PLI on a flash memory 
card 31 so as to be associated with the short-lived 
10 application. 

The following describes the problems that occur when 
short-lived applications are stored on a flash memory card 
31. When a short-lived application is used for news, only 
the most recent application is sent to the recording 
15 apparatus every day. If the recording apparatus 
accumulatively stores every day's news onto a flash memory 
card 31, the limited storage capacity of the flash memory 
card 31 will soon be taken up by such short-lived 
applications . 

20 To stop short-lived applications from taking up too 

much space on the flash memory card 31, the recording 
apparatus should refer to the PLI__RSM__PL and PLI_APP__ATR 
and perform the operations described below. Since 
short-lived applications are stored on the flash memory 

25 card 31 together with PLIs where the PLI_APP_ATR is set 
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to indicate an audiobook^ a recording apparatus can 
determine which PLIs, TKIs, and AOBs correspond to 
short-lived applications by referring to the PLI__APP__ATRs ♦ 
In the PLI for a short-lived application, the value 
5 "FF" is set in the PLI_RSM_PL if all of the tracks in the 
indicated playback order have been entirely played back, 
or at a different value if the playback of the tracks in 
the indicated playback order has not been completed. 
Accordingly, a recording apparatus can know whether a 

10 short-lived application has been played back in its entirety 
simply by referring to the Track_Number in the PLI_RSM_PL. 

After checking the Track__Number in this way, the 
recording apparatus can delete the TKIs, AOBs, and PLIs 
for short-lived applications that have been played back 

15 in their entirety. This stops the storage capacity of the 
flash memory card 31 from being overwhelmed by the 
accumulation of a large number of short-lived applications • 
Note that while the above example refers to the case where 
the recording apparatus refers to the PLI_RSM_PL and 

20 PLI_APP_ATR, the same control can be performed for the 
DPLI_RSM_PL and DPLI_APP_ATR. 

With this embodiment, short-lived applications such 
as news can be downloaded and stored on a flash memory card 
31. Such short-lived applications can be deleted starting 

25 with the applications that have been entirely played back. 
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so that even when a short-lived application such as news 
is produced every day, such short-lived applications can 
be prevented from taking up all of the storage capacity 
of the flash memory card 31. 

5 Although the present invention has been fully 

described by way of example with reference to the 
accompanying drawings , it is to be noted that various changes 
and modifications will be apparent to those skilled in the 
art. Therefore, unless such changes and modifications 

10 depart from scope of the present invention, they should 
be construed as being included therein. 
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What is claimed is: 

1 1. A semiconductor memory card, storing: 

2 an audio sequence in which a plurality of audio objects 

3 are arranged; and 

4 resume information showing a resume position for use 

5 when playback of the audio sequence resumes midway through 

6 the audio sequence. 

1 2 . A semiconductor memory card in accordance with Claim 

2 1, 

3 wherein the resume information includes at least one 

4 of type 1 position information and type 2 position 

5 information, 

6 the type 1 position information showing a type 1 resume 

7 position set according to a user operation, and 

8 the type 2 position information showing a type 2 resume 

9 position that was automatically set when playback of the 
10 audio sequence last stopped. 

1 3- A semiconductor memory card in accordance with Claim 

2 2, 

3 wherein each audio object in the audio sequence has 

4 been provided with unique identification information, 

5 the type 1 position information showing the type 1 
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6 resume position using the identification information of 

7 one of the audio objects, and 

8 the type 2 position information showing the type 2 

9 resume position using the identification information of 

10 one of the audio objects and time information showing an 

11 offset from a start of the one of the audio objects to the 

12 type 2 resume position. 

1 4. A semiconductor memory card in accordance with Claim 

2 3, further storing: 

3 at least one piece of playback route information, each 

4 of which defines a playback route by including the 

5 identification information of at least one audio object 

6 and a playback position of each of the at least one audio 

7 object in the playback route; 

8 the resume information further including specifying 

9 information that specifies one piece of playback route 

10 information, 

11 the type 1 position information and type 2 position 

12 information respectively showing the type 1 resume position 

13 and the type 2 resume position for the audio sequence using 

14 the identification information of an audio object in the 

15 specified piece of playback route information. 

1 5. A semiconductor memory card in accordance with Claim 
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2 4, further storing a piece of supplementary resume 

3 information corresponding to each piece of playback route 

4 information, 

5 each piece of supplementary resume information 

6 including position information showing a position in an 

7 audio object from which playback should start when audio 

8 objects are to be played back in accordance with the 

9 corresponding piece of playback route information, 

10 the position information in the resume 

11 information showing, as the resume position, a position 

12 and an audio object that are indicated in one of the pieces 

13 of supplementary resume information. 

1 6. A semiconductor memory card in accordance with Claim 

2 5, 

3 wherein a first value is set in each piece of 

4 supplementary resume information when playback is complete 

5 for all audio objects whose identification information is 

6 indicated by the corresponding piece of playback route 

7 information, and 

8 a second value is set in each piece of 

9 supplementary resume information when playback is not 

10 complete for all audio objects whose identification 

11 information is indicated by the corresponding piece of 

12 playback route information. 



180 



1 7. A playback apparatus for a semiconductor memory card 

2 that stores (1) an audio sequence in which a plurality of 

3 audio objects are arranged and (2) resume information 

4 showing a resume position for use when playback of the audio 

5 sequence resumes midway through the audio sequence, 

6 the playback apparatus comprising: 

7 receiving means capable of receiving, from a user, 

8 a first playback operation specifying one of the audio 

9 ob j ects and a second playback operation that does not specify 

10 any of the audio objects; and 

11 playback means 

12 for playing back the specified audio object when 

13 the receiving means has received the first playback 

14 operation, and 

15 for reading the resume information from 

16 the semiconductor memory card and playing back the audio 

17 sequence starting from the resume position shown by the 

18 resume information when the receiving means has received 

19 the second playback operation. 

1 8. The playback apparatus of Claim 7, 

2 wherein the resume information shows the resume 

3 position using identification information for one of the 

4 audio objects in the audio sequence and time information 
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5 showing an offset from the start of the one of the audio 

6 objects to the resume position, and 

7 when the receiving means has received the second 

8 playback operation, the playback means starts to playback 

9 the audio sequence from a midway point, which is indicated 

10 by the time information, in the audio object indicated by 

11 the identification information provided in the resume 

12 information. 

1 9. A playback apparatus for a semiconductor memory card 

2 that stores (1) an audio sequence including a plurality 

3 of audio objects and (2) resume information showing a resume 

4 position that has been specified by a user operation, 

5 the playback apparatus comprising: 

6 loading means for loading the semiconductor memory 

7 card; 

8 judging means for judging whether second resume 

9 information has been correctly written onto the 

10 semiconductor memory card loaded by the loading means, the 

11 second resume information showing a resume position and 

12 being automatically set when playback is stopped; and 

13 playback means 

14 for playing back the audio sequence in accordance 

15 with the second resume information when the second resume 

16 information has been correctly written on the semiconductor 
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17 memory card and 

18 for reading the first resume information 

19 from the semiconductor memory card and playing back the 

20 audio sequence in accordance with the first resume 

21 information when the second resume information has not been 

22 correctly written on the semiconductor memory card. 

1 10. A playback apparatus according to Claim 9, further 

2 comprising a storage means for storing a flag indicating 

3 which of the first resume information and the second resume 

4 information should be used for playback, 

5 wherein when the flag indicates the first resume 

6 information, the playback means plays back the audio 

7 sequence in accordance with the first resume information 

8 regardless of whether the second resume information has 

9 been correctly written on the semiconductor memory card. 

1 11. A playback apparatus according to Claim 10, further 

2 comprising: 

3 a receiving means for receiving, from a user, an 

4 operation that indicates which of the first resume 

5 information and the second resume information should be 

6 used; and 

7 setting means for setting the flag in the storage 

8 means in accordance with the operation received by the 
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9 receiving means . 

1 12. A recording apparatus for a semiconductor memory card, 

2 comprising: 

3 receiving means for receiving an operation made by 

4 a user; 

5 playback means for playing back audio ob j ects included 

6 in an audio sequence when the received operation is a playback 

7 operation; and 

8 recording means 

9 for specifying, when the received operation is 

10 a stop operation, a resume position from a playback position 

11 where the user made the stop operation, the resume position 

12 showing where playback of the audio sequence should be 

13 resumed, and 

14 for recording resume information showing 

15 the resume position onto the semiconductor memory card. 

1 13. A computer-readable storage medium storing a program 

2 that has a computer execute a playback procedure for a 

3 semiconductor memory card, the semiconductor memory card 

4 storing (1) an audio sequence in which a plurality of audio 

5 objects are arranged and (2) resume information showing 

6 a resume position for use when playback of the audio sequence 

7 resumes midway through the audio sequence. 
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8 the program comprising: 

9 a receiving step capable of receiving, from a user, 

10 a first playback operation specifying one of the audio 

11 objects and a second playback operation that does not specify 

12 any of the audio objects; and 

13 a playback step 

14 for playing back the specified audio ob j ect when 

15 the receiving step has received the first playback operation, 

16 and 

17 for reading the resume information from 

18 the semiconductor memory card and playing back the audio 

19 sequence starting from the resume position shown by the 
■20 resume information when the receiving step has received 
21 the second playback operation. 

1 14. A computer-readable storage medium according to Claim 

2 13, 

3 wherein the resume information shows the resume 

4 position using identification information for one of the 

5 audio objects in the audio sequence and time information 

6 showing an offset from the start of the one of the audio 

7 objects to the resume position, and 

8 when the receiving step has received the second 

9 playback operation, the playback step starts to playback 
10 the audio sequence from a midway point, which is indicated 
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11 by the time information, in the audio object indicated by 

12 the identification information provided in the resume 

13 information. 

1 15, A computer-readable storage medium storing a program 

2 that has a computer execute a playback procedure for a 

3 semiconductor memory card, the semiconductor memory card 

4 storing (1) an audio sequence in which a plurality of audio 

5 objects are arranged and (2) resume information showing 

6 a resume position for use when playback of the audio sequence 

7 resumes midway through the audio sequence, 

8 the program comprising: 

9 a loading step for loading the semiconductor memory 

10 card; 

11 a judging step for judging whether second resume 

12 information has been correctly written onto the 

13 semiconductor memory card loaded by the loading step, the 

14 second resume information showing a resume position and 

15 being automatically set when playback is stopped; and 

16 a playback step 

17 for playing back the audio sequence in accordance 

18 with the second resume information when the second resume 

19 information has been correctly written on the semiconductor 

20 memory card and 

21 for reading the first resume information 



186 



22 from the semiconductor memory card and playing back the 

23 audio sequence in accordance with the first resume 

24 information when the second resume information has not been 

25 correctly written on the semiconductor memory card. 

1 16. A computer-readable storage medium according to Claim 

2 15, 

3 wherein the computer includes a storage means for 

4 storing a flag indicating which of the first resume 

5 information and the second resume information should be 

6 used for playback, 

7 wherein when the flag indicates the first resume 

8 information, the playback step plays back the audio sequence 

9 in accordance with the first resume information regardless 

10 of whether the second resume information has been correctly 

11 written on the semiconductor memory card. 

1 17. A computer-readable storage medium according to Claim 

2 16, 

3 wherein the program further comprises: 

4 a receiving step for receiving, from a user, an 

5 operation that indicates which of the first resume 

6 information and the second resume information should be 

7 used; and 

8 a setting step for setting the flag in the storage 
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9 means in accordance with the operation received by the 

10 receiving step. 

1 18. A computer-readable storage medium storing a program 

2 that has a computer execute a recording procedure for a 

3 semiconductor memory card, 

4 the program comprising: 

5 a receiving step for receiving an operation made by 

6 a user; 

7 a playback step for playing back audio obj ects included 

8 in an audio sequence when the received operation is a playback 

9 operation; and 

10 a recording step 

11 for specifying, when the received operation is 

12 a stop operation, a resume position from a playback position 

13 where the user made the stop operation, the resume position 

14 showing where playback of the audio sequence should be 

15 resumed, and 

16 for recording resume information showing 

17 the resume position onto the semiconductor memory card, 

1 19. A playback method for a semiconductor memory card that 

2 stores (1) an audio sequence in which a plurality of audio 

3 objects are arranged and (2) resume information showing 

4 a resume position for use when playback of the audio sequence 
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5 resumes midway through the audio sequence, 

6 the playback method comprising: 

7 a receiving step capable of receiving, from a user, 

8 a first playback operation specifying one of the audio 

9 ob j ect s and a second playback operation that does not specify 

10 any of the audio objects; and 

11 a playback step 

12 for playing back the specified audio object when 

13 the receiving means has received the first playback 

14 operation, and 

15 for reading the resume information from 

16 the semiconductor memory card and playing back the audio 

17 sequence starting from the resume position shown by the 

18 resume information when the receiving means has received 

19 the second playback operation, 

1 20. A playback method according to Claim 19, 

2 wherein the resume information shows the resume 

3 position using identification information for one of the 

4 audio objects in the audio sequence and time information 

5 showing an offset from the start of the one of the audio 

6 objects to the resume position, and 

7 when the receiving step has received the second 

8 playback operation, the playback step starts to playback 

9 the audio sequence from a midway point, which is indicated 
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10 

11 

12 



by the time information^ in the audio object indicated by 
the identification information provided in the resume 
information. 



1 21. A playback method for a playback apparatus that uses 

2 a semiconductor memory card storing (1) an audio sequence 

3 including a plurality of audio objects and (2) resume 

4 information showing a resume position that has been 

5 specified by a user operation, 

6 the playback method comprising: 

7 a loading step for loading the semiconductor memory 

8 card; 

9 a judging step for judging whether second resume 

10 information has been correctly written onto the 

11 semiconductor memory card loaded by the loading step, the 

12 second resume information showing a resume position and 

13 being automatically set when playback is stopped; and 

14 a playback step 

15 for playing back the audio sequence in accordance 

16 with the second resume information when the second resume 

17 information has been correctly written on the semiconductor 

18 memory card and 

19 for reading the first resume information 

20 from the semiconductor memory card and playing back the 

21 audio sequence in accordance with the first resume 
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22 information when the second resume information has not been 

23 correctly written on the semiconductor memory card. 

1 22. A playback method according to Claim 21, 

2 wherein the reproduction apparatus includes a storage 

3 unitf or storing a flag indicating which of the first resume 

4 information and the second resume information should be 

5 used for playback, 

6 wherein when the flag indicates the first resume 



7 information, the playback step plays back the audio sequence 

8 in accordance with the first resume information regardless 

9 of whether the second resume information has been correctly 
10 written on the semiconductor memory card. 



1 23. A recording method for a semiconductor memory card, 

2 comprising: 

3 a receiving step for receiving an operation made by 

4 a user; 

5 a playback step for playing back audio objects 

6 included in an audio sequence when the received operation 

7 is a playback operation; and 

8 a recording step 

9 for specifying, when the received operation is 

10 a stop operation, a resume position from a playback position 

11 where the user made the stop operation, the resume position 
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showing where playback of the audio sequence should be 
resumed, and 

for recording resume information showing the 
resume position onto the semiconductor memory card. 
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ABSTRACT OF THE DISCLOSURE 



A semiconductor memory card stores a plurality of 
audio objects (AOBs) that compose a plurality of tracks 
5 and playlist information showing a reproduction order for 
the tracks. The semiconductor memory card also stores 
as resume information (PLMG_RSM_PL) , (1) a Playlist_Number 
showing which playlist information was used the last time 
playback was performed for the semiconductor memory card, 
10 (2) a Track Number showing the last track to be played back, 
and (3) a Playback_Time showing a position at which where 
playback was stopped as a time expressed in relation to 
the start of the track. 



193 



FIG. 1 




FIG. 2 




2/7 8 



ill 
«!■ 
CI 
^0 
CI 

m 

o 
m 
ill 
m- 

CI 



CO 

d 
I— I 




A ro 




3/7 8 




< 

d 



< 

o 

CO 



> — i 

Q 



Set: 



Q 

W 
NI 

1—4 

o 
;=) 



oo<C 



^^^^ 



4/7 8 



d 

















CIS 




ft.*; 














































■—J 






















>- 






















Cat-, 














CLJ> 






. , 






































































































CO 


CO 
























































=^ 
























E . 














!< 




!^ 
























CO 


&r.- 




























— ^ 


























































































c — 


















era 
















— i 


•—J 










































£ — * 






































po 






Q 








<=:=> 














crr> 






-o 
































— 3 




& 
























CO 






E — 


































































o 
























£: 












CJ 












V5 












CJ 

























l;5 



OS 



OS 



CiS 
CZL3 

&5 



OS 



OS 

i 



OS 

&5 



OQ 



OS 



OS 



OS 



oi 



OS 



OS 
CO 



OS 



as: 



OS 



era 
OS 

on 



OS 



i 



OS 



CD 
OS 

fc5 



os: 

IE- 
CO 



C_> C_3 C_5 



OS 
— 3 



CO 
cm 

o=; 

CO 



<4-i 



< 

pi: 
< 

< 
w 



O 
< 



H 

CO 
00 



O 
O 

O 00 



< w 

Plh oo 



2; 
o 

o 
o 

.-I 



o 

o 
w 
ci^: 

I— I 

Q 



00 



o 

O 

w 

Q 
o 

00 PJ 



5/7 8 




6/7 8 




7/7 8 



USER DATA AREA 

s 

Root 



FIG. 8A 




SD_AUDIO. PLM I 

" 1 



SD_AUDIO. TKM 



aoboolsaI) 

AOB002. SAT] 



AOBQ03. SaTI 



AOB004. SAl 



AOB005. SAl"| 



AQB006. SAl) 
AOB007. SAl) 



AOB008. SAl") 



Other Directories 



Other File 



PROTECTED AREA 



FIG. 8B 




AOBSAl.KEY. 



8/7 8 



File Key #1 
File Key #2 
File Key #3 
File Key #4 
File Key #5 
File Key #6 
File Key #7 
File Key #8 




CD 

d 

t— H 



9/7 8 



11 
o 
^fl 
a. 

a 
III 
m 
m 

CI 

cr 




—I 

O 
< 



PQ 
O 
< 



O 

o 
-J 

PQ 
O 
< 



mm 



mm 

CQ 
O 
< 




^1 

PQ 
O 
< 



1 0/7 8 



FIG. IIA 

MPEG2-AAC format 


format 


Audio_Data_Transport_Stream(ADTS) 


Profile 


Low UomplexitylLCj protile (mandatory) 


hifrpfp npr rhannpl^''^ 


ueiween iDKuius^rnin.janu / ^KDit/s^mcLX.j 
Other bitrates are optional. 


^amnlinc frpniipnrv 


40 AFiz^rnmiQaLoryj 
44 1 kH7fm?fnd;^fnrvl 

32 kHz(mandatoiy) 
24 kHz(mandatory) 
22.05 kHz(mandatory) 
16kHz{mandatory) 


channel_contiguration 


singie_channei_element(mandatoryJ 
channel_pair_element(mandatory) 


niimber_or_data_blocksJnJrame 


1 header/ 1 ravv_data_blocK(mandatoiyj 


FIG. 11 B 

MPEG layer 3 format 


format 


MFEG-l layers 

MPEG-2 layer 3 low sampling frequency 


bitrate per charmer* 


MPEG l:between IBkbit/s and 9Bkbit/s 
MPEG 2 LSF:between 16kbit/s and 80kbit/s 
Other biu-ates and variable bitrate are optional. 
Bitrate index "0000 ".i.e. "free fomiat" is not supported. 


sampling_frequency 


48 kHz ^ 

44.1 kHz 
32 kHz 
24 kHz 
22.05 kHz 
16 kHz 


mode 


stereo 

joint_stereo 
single_cannel 


FTP 1 1 C 

r i<or . 1 1 \^ Windows Media Audio format 


format 


Windows Media Audio format 


bitrate per channel" 


between 8kbit/s and 80kbit/s 
Other bitrates are optional. 


sampling_frequency 


48 kHz 
44.1 kHz 
32 kHz 
22.05 kHz 
16kHz-. 


mode 


monaural 
stereo 


1 1/7 8 



CXI 
, — I 

d 

I— H 




1 2/1 8 




1 3X78 



FIG. 14 



sampling frequency 


FNs_Middle_TMSRTE 


AAC 


MPEGlayer3 


WMA 


48kHz 


47*N 


42*N 


XXX 


44.1kHz 


43*N 


38*N 


XXX 


32kHz 


32*N 


28*N 


XXX 


24kHz 


24*N 


42*N 


XXX 


22.05kHz 


22*N 


38*N 


XXX 


16kHz 


16*N 


28*N 


XXX 



M N BEING THE PLAYBACK PERIOD "TIME_LENGTH" 
OF AN AOB_ELEMENT TO AN ACCURACY OF 1/lOOOTH 
OF ONE SECOND 



1 4/7 8 




1 5/7 8 



od 



CO 

o 



oo 

o 



o 







PI 














CO 



















CQ 
O 



o 



CO 

oo 



OO 
< 



oo 



O 



oo 



CQ 
O 



oo 



OQ 
O 



oo 
CQ 

o 



CO 



CO 
00 

1. 



CQ 
CD 



uo 

oo 

< 

„\ : 



00 

< 



CQ 

O 



C<3 

CQ 
O 



CO 

oo 

< 



'CV3 
CO 



CO 



oo 



CO 



CO 
CO 

i_ 





















CQ 






o 

















cu 



CD 



CD 



CQ 



CO 
CO 

i_ 



CO 



ClO 

o 
oo 



Q 

o 
oo 



c: 
o 
oo 



OQ 



o 
oo 



cr 

CD 
OO 



o 



o 



CQ 

CO 



CO 
< 



OO 



Cell 



is 



E— -cyo 



CO 



o 

I — I 

1 6^-7 8 




1 7/7 8 



FIG. 18 



(PLMG) 



Playlist Manager Information (PLMGI) 


FIXED 


f 


Default Playlist Information (DPLI) 


LENGTH 
(2.5KByte) 


Playlist Informationfl {PLI#1) 


FIXED LENGTH' 
(512Byte) 




• 
• 
• 






Playlist Information#n(PLI#n) ^ 

(l^n^99) 


FIXED LENGTH' 
(512Byte) 




;^rack ^f^^^f^^/^^ 


FIXED LENGTH' 
(1024Byte) 




• 
• 
• 






Track Information #m(TKI#m) 


FIXED LENGTH' 
(1024Byte) 





(l^m^999) 



1 8^7 8 




19/7 8 



Pi 
w 
a 
Pi 
o 

o 

E- 

o 

w 
Q 



o 
o 



< 

Q 
COL, 



cq 



CO 
>^ 

O 

N ( 



Q 

CO 



00 



> 
00 



CO 



O 

ZD a 



> 

<D 
CO 
CD 



00 

o 



X3 



00 

o 



CO 
W 
E-* 
>^ 
CQ 
CO 



o 
o 

h — I 

) — 1 

o 

Q 



:scQ 



O 
E- 



E- 

•z 

o 
o 



< 

:z: 

Q 



CtiO-, 



CN3 
CV3 
X 

CD 

£■ 

CN3 



w 

w 
-J 
w 

I 

CQ 
O 
< 



CD 
N 

CO 



w 

CO 



00 



If 



CD 
CO 



CD 






















Pi 


00 


CO 








E- 



2 0/7 8 




O ^ O \ CD 

O \ CVI \ CD 

"-CXI < > > ^ <-A^^ 

^ CO CD 



C>0 
OQ 



o 



) 
1 
I 
t 
1 


^AR2 


! ! 

: <: : 








r« ^ 


fi »j 


< >I 



d 
►—I 



O 
< 



CV3 

o 
< 



CO 

w 
w 

PQ 
O 
< 




2 1/78 



FIG. 22 



bi5 bi4 bi3 bi2 bii bio b9 b8 



TKI.ID 


TKI IDEOTIFIER(=A4) 


TKIN 


TKI NUMBER 


reserved 


RESERVED 


TKI_SZ 


TKI SIZE 


TKLLNK_PTR 


LMPOMERTONEnTKI 


TKI_BLK_ATR 


BLOCKATTRBUIESOFTKI 


TKI_PB_TM 


PLAYBACKPERIOD 


TKI_AOB_ATR 


AUDIOATMBUTESOFTKI 


ISRC 


ISRC 


BIT 


blockinfor.™ntable 



reserved 



] 



_b7 bi b5 b4 b3 b2 bi bo 

Block Attributel 



reserved 



Block Attribute 

'OOOB" : 1 SONG IN TKI 
•OOIB" : START OF SONG IN TKI 
"OlOB" : MIDDLE OF SONG IN TKI 
"01 IB" : END OF SONG IN TKI 
"lOOB" : DELETED TKI 
"lOlB" : TKI IN INITIAL STATE 



bl9 



bi6 bi5 



b8 



Audio coding mode 



bitrates 



] 



hi 



b5 b4 b3 hi bi bo 



1 V 

t \ 
t ^ 
I > 

I 



Fs Number of channels reserv^edj 



\ hn b78 hll b76 b75 b74 b73 b72 



Validity- 



reserved 



b71 b/O b59 b68 b67 b66 b65 b64 

Country Code(I$RCli) | 



reserved 



b63^ b62 b6i beo b59 b58 b57 b56 

Country Code(I$RC#2) | 



reserved 



b55 b54 b53 b52 b51 bl50 b49 b48 

reserved | First Owner Code (ISRC#3) | 



b47 b46 b45 b44 b43 b42 b4l b40 

First Owner Code(ISRC#4) | 



reserved 



: b39 b38 b37 b36 b35 b34 b33 b32 

reserved | First Owner Code(ISRC#5) \ 



\ b31 b3Q b29 b28 b27 b26 b25 b24 

1 lYearAordingcodeM |Year-Qf-RecordiaacQde(ISRCI^ j 



1 b23 b22 b21 b20 bi9 bl8 bi7 bl5 

Recording code(ISRC#8) | Recording code(ISRC#9) \ 



\ ^ bi5 h\\ bi3 bi2 bii biQ b9 b8 
Recording code(ISRC#10) Recoflfeigcdtofeg-itefli^^^ 



; b7 b6 b5 b4 bs b2 bi bo 



Recording-item code(ISRCI12) reserved | 



2 2/7 8 



s 



t 



Cx3 
CO 



< 

d 

pi. 



IS 



Cx3 



CD 
on 

cy-:t 

i 



i 



CO 
CO 



CO 



crs. 



S3 



t>3 
OO 



oo 



oo 

CO 



CO 



2 ^ 

CQ' 

-St: 



Ci3 



CO 

o 

CN3 



CO 



lS3 



CQ 



^ CD 



1^ 



OO 



o 



CO 



CQ 
CD 



CQ 



oo 



o 

CO 



CD 

CD 
CD 



oo 

Em. 



PQ 

CO 

d 

l-H 



oq 
uo 



O 

I 



o 

oo 

CXI 

d 

I— I 



o 



< 



00 

c 

iS 
O 



C 

cr 



c 



2 



X 
X 
X 



CO 

cu 

d 
< 
< 

o 
to 

o 
o 
o 

CVJ 

II 

X 
W 

E- 



N 



N 



E- 
o 

ZCX4 

wo 
wo 

Pi 

2< 

>-.W 

% 

w<o 
zoo 



2 3/7 8 




2 4/7 8 




d 

J 1 



•4—1 

CD 

£ 



o 
< 



-t-> 

c 

CD 

s 

w 

o 
< 



s 

•1— t 

o + 

T— I tt-l 

sq ^ 



> ! 

O-TH^ I 





+ 



CD 

-a 



C/5 



o 

B 
•a 

d 

+ 



+ 
s 

2 
00 

o 



2 5/7 8 




a 

CD 

c 

CL. 

£ 



CD 

s 

I 

CD 



CD 
"E 

s 

o 
< 



PQ 
O 
< 



c: 

B 
^ qj 

I 

o 



O Co' 



CO £ 
o o 

X 

X 

+ 

m 

X3 



CO 



e 

to 



o 



1^ 



i 



< 

CD 

d 

PL. 



+ 

II w 

^ ^ 1 — i 

^ I 
O CO 

-I— > 
CL, 

S 



o 

CD 
CO 

c 
w 

I 

a. 

£ 



■PQ 

.CD 

d 

2 6/7 8 



+ 

PQ 
O 
< 



CO 

o 

< 



PQ 
O 
< 



PQ 
O 
< 



o 

CD 

■i~> 
c 
W 



-I- . 
E 

OJ 



X 



CD 

"£ 
a 

u, 
fx. 
O 



< 



CJ 
CD 

cvj H 

Si? 



CQ 
O 



O 



en 

E 

<L> 

o 

^ i 



fT] E— ' 
O co' 



CD 

E 



PQ 
O 
< 



1 1 ^ 



H + 
CO 



o 
p^ 

Q 
O 

Pi 
w 

Oh 



J 



CO 



o 

H 
II 

CD 
CO 



Pi 



CO 
t — I 

to 



£ 




2 7/7 8 




2 9/78 



<: 

o 

CO 

d 
I — I 



O 
< 



c 
I ^ 

-J 





1 — 1 






1 

PQ 






O 




< 

















CO 



■< 



..I 

g 

CO 



-a 



in 




CO 



CO 



PQ 
o 

CO 

d 

J— 4 



CD 

o 
< 



I 

CQ 



o w 
—1 



J 



J 




C/5 

II 



,1 



I 



3 0/7 8 





3 1/7 8 



FIG. 32A 

FIRST TRACK 



NEXT TRACK 



AOB#n-l 




Y 

AOB_TYPEl 



+ 



AOB#n+l 



y 

AOB_TYPEl 



FIG. 32B 

FIRST TRACK 



NEXT TRACK 



AOB#n-l 



AOB_TYPEl 



+ 



AOB#n 



AOB_TYPE2 



FIG. 320 

FIRST TRACK 




NEXT TRACK 



AOB#n+l 



AOB_TYPEl 



FIG. 32D 

FIRST TRACK 





AOB#n-l j 


AOB#n 1 


V. J V f 

AOB_TYPEl AOB_TYPE2 



NEXT TRACK 




FIG. 32E 

FIRST TRACK 



NEXT TRACK 





AOB#n-l 1 


AOB#n 1 


, ' V ^ , 

AOB_TYPE2 AOB_TYPE2 



+ 



AOB#n+l 



AOB_TYPEl 



3 2/7 8 




■ pq 

". CO 
CO 

d 

3 3^7 8 



< 
CO 
CO 

d 

I — I 



CO 












] 








/ 






Tt 


/ 


r — 








1 1 


















w 








CQ 




cq 




:^ 




:s 






— ^ 










V ; 




o 




<o 


w 




W 




r , 

c— ^ 




f— 1 




00 




OO 




D 




















o 




C , 








oo 




OO 




1 — 1 












l—H 

tin 












o 




o 








t— 1 
CO 
















w 








H 








X 


T 1 




< 


w 


< 


w 


00 






:^ 






< 




< 




















> — 1 




_1 








>— H 














CM 




CO 


< 


O 

o 


< 


o 
o 




PQ 




cq 


w 


o 


w 


O 


-J 


< 


\ — 1 


< 













3 5/78 




o 



3 6/78 



cy 



CD 
OO 



CD 



0^ 



cy 
I 

OO 



Oh 



C7> 



o 



CD 



O 
111 

a 
a 

a 
III 
m 
ill 

Q 
CI 



CO 

d 
I — I 



00 



<4-H 



cd 



< 

00 



CO 

2 

00 



OO 



CO 



00 



00 



CO 

CO 



w 

00 



X3 



CO 

a: 



t i 

Q 

o 
o 
w 

00 



O 



< 

Q 

00 



OO 

2 
«' 

( 

00 



2 

00 




CO 



OO 



CO 
CO 



CO 



00 



00 



X 



OO 
CNJ 



o 

OO 



o 

LO 



CD 



H 

J— t 

o 
o 



o 

o 

J 

CO 

P 



< 

Q 

00 



CO 

00 



00 

CO 



00 



00 



CO 

c^' 

:z; 



E- 
OO 



CX4 



3 7/78 



CI 
m 
IJI 
ill 
ci 

u 

O 
ill 

m 
m 
a 
a 



oo 

CO 

d 




3 8X7 8 



Oh 
Q 

O 
W 
D 

) f 

H 
< 



tx4 



< 

CO 

d 

I — I 









































































































oo 


:^ 


:^ 

CxJ 










HE 


CxJ 


he: 


CxJ 












E— ' 










o 


o 


O 


CxJ 
Q 










:^ 












CxJ 


CxJ 


po 


s 






CQ 


DQ 


CQ 


2 










E— ' 
















-< 


1 






<C 






CXh 








Cu 


cu 




o 






CO 


CO 


CO 


Cx:: 








Is,TH 


re 








1 




Is,T 




i 

oo 


oo 
























T.OCCl 








O 
>- 


O 


o 
>- 


iNm 






ALIT 


£ — ' 




EL 










CxJ 

CO 










CxJ 


oo 


:^ 








ZD 


oi; 


cx: 












cu 










cu 




TKI 


cu 


o 


o 






















E— 












o 


r\ fc T 

ON 












:zD 








CxJ 


CxJ 


o 






OO 




OO 


oo 


rc 






cxj 




CxJ 


CxJ 












0:i 






Q_ 




cu 


CU 


CJ 






O 


o 




o 


UNUSE 


UNUSE 






ESON 




o 

oo 

CxJ 




:^ 
















o 


o 


O 






CO 














CxJ 














e- 






















































# 




ID 1 


— 1 < 




— < < 


CD 1 






zz> < 






— 1 < 






Z5 C 


Z3 < 


3 < 









CD 



CV3 

to 



OO 



X3 

> 

CU 
CU 



0^; 

3 



Q 



p 

s 

) — I 



J' 

Oh 
Q 



P 

c 
o 

C^J 

c 

1— I 

c 



CO 



— I 

I 



v 



CQ 

CD 
CO 

d 





CM 


oo 










a, 


CL, 








CO 


CO 




























Q 


Q 


Q 



Q 



3 9/^7 8 



00 



S 

OH 



(-1 
H 



a 

S-i 



O (J 



cuE— * 



a 

2 



2 



5 

Oh 



00 



CX) 



CO 



Os3 



-J 

CU 

Q 




o 



4 0/7 8 




4 1/78 



FIG. 43A 



DPLI 

DPL_TK_ATR 
DPL TKIN 



, — ' s ' V — ' ' 

DPL.TK.SRFf! Wljim miM 




Track 


Track 


m 


Head of 
Track 


Vlidpoint 
ofTrack 


Midpoint 
ofTrack 


End of 
Track 




#1 


#2 


#4 


#5 
i 


#6 


#7 



TKMG 




FI G. 43B 

DPLI 

DPL_TK_ATR 
DPL TKIN 



Track A Track B Track E Track D Track C 




TKMG 



AOBOOLSAl 



AOB002. SAl 



AOB008.SA1 



J 



4 3/78 



FIG. 44A 



DPLI 

DPL_TK_ATR 
DPL TKIN 



r—" V 

DPLMl 


11 A I 


Track 


■ 


Track 


Head of 
Track 


Vlidpoint 
of 1 rack 


Midpoint 
of Track 


End of 
Track 


Track 


#1 


#3 


#4 
^ 


#5 
/ 


#6 
^ 


#7 


#8 



TKMG 




TKI#4 
Head of 
Track D 



TKI#5 
Vlidpoint 



of Track Diof Track D 



TKI#6 
Vlidpoint 



TKI#7 
End of 
Track D 



TKI#8 
Track E 



AOBOOl.SAl 



AOB003. SAl] 



AOB005.SA1 



AOB002. SAI 



AOB004. SAl 



FIG. 44B 



] ^ [AOBQ07. Sa7] 



AOB006. SAl 



AOB008.SA1 



j 



DPLI 

DPL_TK_ATR 
DPL TKIN 



Track A Track C 



Track D Track E 





1 












DFL.M 


Track 


Track 


Track 


Head of 
Track 


Midpoint 
of Track 


Midpoint 
of Track 


End of 
Track 


Unused 


#1 


#3 


#4 


#5 



#6 


#7 


#8 


#2 






DTll-ADTlZ 



DT13 



TKI#3 
Track C 



TKIM TKI#5 
Head of MidpokuMidpoinj 
Track DofTrackE of Track 



TKI#6 I TKI#7 
End of 
Track D 



TKI#8 
Track E 



AOBOOl.SAll AOBOOS.SAll J 


AOB005.SAl)7 


AOBOOISAl) 1 




AOB004. SAl] 


AOBOOe.SAll 


AOBOOS.SAl] 



4 4/78 



FIG. 45A 



DPLI 

DPL_TK_ATR 
DPL TKIN 



Track A Track B Track C 



DPiJK.SSP?! mjmi DPL K mm IK dpi U m dpi is SR?-^DPL TK SRf?JDPL TK S8?I8 

' ~ r — '' — ^ ^ — " ■ 



Track 
#1 



Z 



Track 



TKMG 



1 



Track 
#6 



TKI#1 
Track A 








; TKI#3 
^ Track B 


''//// 


TKI#5 
Unused 



TKI#6 
Track C 



AOBOOl.SAl 



AOB003. SAl 



FIG. 45B 



AOB006. SAl 



3^ 



DPLI 

DPL_TK_ATR 
DPL TKIN 



Track A Track B Track C 



Track D 

mSmm]^^ DPL n %m\ 




TKMG 




TKI#3 
Track B 




TKI#5 
Unused 




TKI#6 
Track C 



AOB003. SAlj ^ ^efe. S^lj ^ 



AOB006.SA1 



) 




AOB004.SA1 



AOBOOy.SATj 

AOBOOS.SAlj 



4 5/7 8 



FIG. 46A 



DPLI 

DPLJK_ATR 
DPL TKIN 



Track A Track C 



Track D 



Track E 



kymi 


■ — ' — ^ V — ' — \ 

DPL.OT DrLjneriLM} DPL mi DPLJK mDPL.TK.SRF?! 


DPL.M8 


Track 


m 


Head of 
Track 


Midpoint 
of Track 


Midpoint 
of Track 


End of 
Track 


m 


Unused 


#1 


#4 


#5 


#6 


#7 


#2 



TKMG 




TKI#4 
Head of 
Track D 



TKI#5 TKI#6 TKI#7 
Midpoint Midpoint End of 
of Track D of Track D Track D 



AOBOOl. SAl 



J 



FIG. 46B 



AOBOOS.SAl) I 


AOB005. SAl) ^ 


AOB007. SAll 






AOB004. SAl] 


AOB006. SAl) 


AOBOOS.SAlj 



DPLI 

DPLJK_ATR 
DPL TKIN 



Track A 


Track C 




Track D 










C?:iKSi?=:: 




Track 






Head of 
Track 


Midpoint 
of Track 


Midpoint 
of Track 


End of 
Track 


Unused 


#1 






#4 


#5 


#6 
/ 




#2 




TKMG 







TKI#1 
Track A 


TKI#2 
Unused 





TKI#4 
Head of 
Track D 




TKI#6 
of Track D 



TKI#7 
End of 
Track D 




AOBOOL SAl 



AOBG03.SA1) -/ 


AOBOOS.SAl) / 


AOBOO7.SA1] \ 




AOB004. SaTI 


AOBOO6.SA1) 


AOBOOS.SAlj 



4 6/78 



FIG. 47A 



DPLI 

DPL_TK_ATR 
DPL TKIN 



Track A Track C 



Track D 



Track E 



DPLJK.Sr;i DPI TK SilF^D?LlSR??3D?LlS!IP^l DPL Ti DPL I SRPr^DPL IK SRf?J DPL TK M 




TKMG 



TKI#l 
Track A 



TKI#2 
Unused 



TKI#4 
Head of 
Track D 



TKI#5 
Midpoint 



TKI#6 
Midpoint 



of Track C of Track Q Track 



TKI#7 
End of 
D 



AOBOOl.SAl 



AOB003. SAl 



FIG. 47B 




TKI#8 
Track E 



AOB007. SAl 



AOB008. SAl 



DPLI 

DPL_TK_ATR 
DPL TKIN 



Track A Track C Track F 



Track D 



Track E 




kjim 


DPLM?5 


WiJiM 


DfLJi(.S[!?¥D?L.M' 


Head of 
Track 


Midpoint 
of Track 


Midpoint 
of Track 


End of 
Track 


Track 


#4 


#5 


#5 
^ 


#7 
/ 


#8 



TKMG 



TKI#4 
Head of 
Track D 



AOBOOl.SAl 



TKI#5 

Mm 



TKI#6 



TKI#7 
End of 
Track D 



TKI#8 
Track E 



AOB005.SA1 




AOB007.SA1 




AOB004.SA1I AOB008.SAI 



AOB008.SA1 



J 



4 7/7 8 



FIG. 48 




4 8/7 8 



FIG. 49 



MENU: 




PLAYLIST#1 
PLAYLIST#2 
PLAYLIST#3 
PLAYLIST#4 



4 9/78 



FIG. 50A 



MENU: 

DEFAULTPLAYLIST 



TRACK#2 
TRACK#3 
TRACK#4 
TRACK#5 



FIG. SOB 



MENU: 

DEFAULTPLAYLIST 
rTRACKff 



TRACK#3 
TRACK#4 
TRACK#5 



FIG. SOD 




MENU: 

DEFAULTPLAYLIST 
TRACK#1 



0 



TRACK#3:i' 
TRACK#5 




FIG. SOC 



MENU: 

DEFAULTPLAYLIST 
TRACK#1 
TRACK#2;1^ 



TRACK#4 
TRACK#5 




FIG. SOE 



MENU: 

DEFAULTPLAYLIST 
TRACK#1 



TRACK#3 



PLAY | -INDICAT£STHATTRACKf2SHQULDBEPIAYF,DEACK 



Playlist [ -1NDICATESTHAT1MCKI2SHO0LDBEEDI1D 



5 0/7 8 




5 1/78 




CO 



< 





















Q 


o 


o 






O 




ORI 




i 























CD 
>- 



■J 



O 



CM 

m 

d 

J — t 



13 
o 



< — > 



CX4 



CQ 



o 



o 



o 

Q 



CO 



1. 



5 2/78 



FIG. 54A 



DOUBLE BUFFER 



|CARDCQNNECTQR[ xi 



FLASH 
MEMORY 
CARD ' 



^31 




>wp2 



a CLUSTERQ031 



r6 r7 r8 



■r9 



AOB_ 
Frame 

IQ-^ 



DESCRAMBLER 



FIG. 54B 




5 4/78 



FIG. 55 



C AOB FILE READ PROCEDURE ^ 
I 



.SI 



PlayListManager READ AND A LIST OF THE 
Default_Playlist_Information and PLIs AND 
DISPLAYED 



,S2 



WAIT FOR INDICATION 
FOR WHICH OF THE DefauIt_Playlist 
AND PLIs IS TO BE USED FOR 
PLAYBACK 



WAIT FOR 
INDICATION 



#w 



Default_Playlist SELECTED 



DPL_TKIN#z INDICATED BY THE DPL_TKIN OF THE 
DPL_TK_SRP#w IN THE Default_Playlist INFORMATION 
WRITTEN INTO THE TKI STORING AREA 



54 



TKI#z WITH THE SAME 
NUMBER AS TKI#z SPECIFIED 



I 



.S5 



.S6 



ACCESS PERFORMED TO THE PROTECTED AREA . 

File key#z HAVING THE SAME NUMBER AS THE 

AOB FILE#z READ FROM THE ENCRYPTED KEY STORING FILE 



File key#z INDICATED TO THE DESCRAMBLER 7 [ -^ 



S7 



FIRST CLUSTER POSITION FOR THE AOB_FILE#z 
SPECIFIED IN THE DIRECTORY ENTRY 



,S8 



.S9 



INDICATED CLUSTER READ FROM THE FLASH MEMORY CARDI 




YES ^^Sl l 

CLUSTER INDICATED BY THE FAT VALUE READ| 




S13 



c END :> 



5 5/7 8 



FIG. 56 



(AQBJRAME OUTPUT PROCEDURE^ 




AOB_FRAME#x IN THE AOB_ELEMENT#y DETECTED AT A 
POSITION NO EARLIER THAN THE Data_Offset OF BIT#z IN 
TKIfZ IN THE CLUSTER FOR AOB FILEfz 



AOB_FR^ME#x OUTPUTTED TO THE DESCRAMBLERT^ 



,823 



824 



play_time ^ playjime-f PLAYBACK PERIOD OF AOB_FRAME#x 
playjata ^ playJata+DATA LENGTH OF AOB_FRAME#x 



,825 



NEXT AOBJRAME DETECTED FROM 
ADTS HEADER OF AOB FRAME #x 



#x^#x+l 



r 



S27 



I AOBJRAMEIx OUTPUHED TO THE DESCRAMBLERTj 



play time ^ play_time+ PLAYBACK PERIOD OF AOBJRAMEIx 
playjata ^ playjata + DATA LENGTH OF AOBJRAMEIx 





5 6/7 8 



FIG. 57 



#y^#y+l,#x^l 1 ^ 



S32 



FIRST ADDRESS OF AOBJLEMENTf y 
CALCULATED BY REFERRING TO THE TKTMSRT 



,S33 



AOB_ELEMENT#x DETECTED FROM FIRST 
ADDRESS IN AOB_FRAME#y 



,S34 



S35 



I AOB JRAME#x QUTPUTTED TO THE DESCRAMBLERl j ^^^ 



playjime ^ play_time+ PLAYBACK PERIOD OF AOB_FRAME#x 
playjata ^ play_data+DATA LENGTH OF AOB_FRAME#x 



NEXT AOBJRAME DETECTED FROM ADTSj 
HEADER OF AOB_FRAME#x 

T 



#X' 



#x+I Y 



S38 



I AOB JRAMEfx OUTPUHED TO THE DESCRAMBIERTI c. ' 

playjime playjime + PLAYBACK PERIOD OF AGBiRAMEliT I 
playjata ^ playJata+DATA LENGTH OF AOBJRAMEfx | 





#y^#y-Fl,#x^"TT ^ 



S43 




5 7/78 




5 8/7 8 



FIG. 59A 



AOB_ 
Frame 



AOB Element#l 



AOB Element#2 



A0B_Element#3 



PLAYBACK POINT 
PLAYBACK TIME CODE=00:00:00. 000 

FIG. 59B 



AOB_ 
Frame 



AOB Element#l 



AOB Element#2 



AOB Element#3 



] 



PLAYBACK POINT 
PLAYBACK TIME CODE=00:00:00. 020 

FIG. 590 



AOB_ 
Frame 



AOB Element*! 



AOB Element#2 



AOB Element#3 



i 



PLAYBACK POINT 
PLAYBACK TIME CODE=00:00:00. 040 

FIG. 59D 



AOB_ 
Frame 



AOB Element#l 



AOB EIement#2 



AOB Element#3 



] 



PLAYBACK POINT 
PLAYBACK TIME CODE=00:00:00. 120 

59/78 



FIG. 60 



Cfqrward search procedure^ 



.S61 



AOB„FRAME#x TO #(xH-fW - 1) IN AOB_ELEMENT#y 
INPUTTED INTO DESCRAMBLER 7 



.S62 



-X T f (i) . play_time^play„time •^ t 
play data-^-play dataTd(t) 
WHERE f{t): NUMBER OF FR.^.MES CORRESPONDtN'G TO IMTERiMIHENT PAYBACK PERIOD 
m A.MOUNT OF DATA CORRESPONDING TO IXTERMinENT PLAYBACK PERIOD 



xS63 



INCREMENTED AOBJRUiE#x 
^COMPARED WITH TOTAL NUMBER OF FmiES 
IN AOB_ELEMENT^?Y. AND JUDGEMENT MADE 
AS TO \A/H£THER INCREMENTED AOB FRAiME#x IS 
JMTHIN THE TOTAL NUMBER OF FRAiMES IN 
AOB_ELEMENT?y 



JYes 




Judgement AS to 

WHETHER AN AOB_ELEMENT 
JTHAT FOLLOWS AOB_ELEMENT#^ 
^ EXISTS? 

Tes 



.S54 



No 



^S65 



AOB„FRAME#x ^ AOB_FRAME#x - (NUMBER I 
OF FRAMES IN AQB,ELEMENT#y) | 

866 




'-f(skip_time). play.time^play.to -rskip.time 
play daEa*-play daa-rdtskip^time) 
WHERE skip.tirr^: MERNtnTENT SKIP PERIOD USED WHEN INTERMnTEM 
PLAYBACK IS PERFORMED 
f(skip_time): NUMBER OF FRAMES CORRESPONDING TO MERMmENTSKIP PERIOD 
d(5kip time): AMOUNT OF DATA CORRESPONDC^ TO INTERMmENT SKIP PERIOD 



TNCREMENTED^'"*--- _>S68 
AOB FRAME #x COMPARED 
rn TOTAL NUMBER OF FRAMES IN AOB ELEMENT? 
AND JUDGEMENT MADE AS TO WHETHER INCREMENTED 
AOB FRAMEIx IS WTTHIN THE TOTAL 
" NUMBER OF FRAMES IN 
AOBJLEMENT^v 



JDGEMENT AS 10""""-==-^ 
WHETHER AN AOB„ELEMENT THAT 
POLLOWS AOB„ELEMENT#y EXIST 



No 



AOB>'RAME#x - AOBlFRAMK^x -(NUMBiiR|^S70 
OF FRAMES IN AOB_ELEMENT#y ) 



r 



FIRST ADDRESS OF AOB„ELEMENT#y CALCULATED 
BY REFERRING TO THE TKTMSRT 



r 



AOB_FRAME#x DETECTED BY PERFORMING 
A SEARCH FOR THE ADTS HEADER. STARTING FROM THE 
FIRST ADDRESS OF AOB_ELEMENT#y 



573 



6 0/78 



FIG. 61 A 



AOB_ 
Frame 



A0B_Element#51 


AOB_Element#52 


AOB_Element#53 



























PLAYBACKPOINT 

PLAYBACK TIME CODE=00:00:01. 000 

FIG. 6 IB 

TMSRTE entry #51 



AOB_ 
Frame 



AOB Element#51 AOB Element#52 



AOB Element#53 



FRAMES FOR INTERMITTENT PLAYBACK 
PERIOD INPUTTED INTO DECODER 

PLAYBACK TIME CODE=00:00:01. 240 



FIG. 610 



AOB_ 
Frame 



TMSRTE entiy#52 

r 



AOB Element#51 



-SK 



PPED PERIOD-^ 



AOB Element#52 



"RAME 



AOB Element#53 



] 



OSITION AFTER SKIPPED 



PERIOD(x=62(=1240/20)) 
PLAYBACK TIME CODE=00:00:03. 240(2.000sec+L240sec) 

FIG. 6 ID 



AOB_ 
Frame 



A0B_Element#51 


A0B_Element#52 


A0B_Element#53 
























/ 


r r - - 




















-SKIPPED PERIOD-^ 




< 


FRAj\ 


[ESFORINTERMinENT PLAYBACK 



INPUTTED INTO DECODER 
PLAYBACK TIME CODE=00:00:03. 480 

6 1/78 



FIG. 62A 




FIG. 62B 



BIT FNs_lst_TMSRTE 80 
FNs_LasLTMSRTE 50 
FNs_Middle_TMSRTE 94 



Audio_ 
Frame 



AOB Element#148 


AOB Element#149 


AOB Element#150| 
















:i3L 


llil 1 1 



PLAYBACK TIME CODE=00:04:40 {=280sec) FRAME POSITION 

280sec= (80(=FNs_lst_TMSRTE) + 148*94 AT WHICH PLAYBACK 

(=FNs_Middle_TMSRTE) + 8*20msec SHOULD START 

6 2/7 8 




6 3/7 8 



FIG. 64 

DIVISION PROCESS INDICATED 




Yes 

TRACK SELECTED USING THE CURSOR 
KEYS SHOWN AS OBJECT FOR EDITLNG 



Yes 



S119 



TRACK SELECTED USING THE CURSOR 
KEYS SPECIFIED AS OBJECT FOR EDITING 



'8120 



PLAYBACK COMMENCED FOR 

TR.CK SELECTED AS OBJECT FOR EDITING 




Yes 



S122 
USER"""-^ Yes 




S124 



PLAYBACKTIMECGDECHANGEDIN 
ACCORDANCE WITH ROTATION OFTHEJOG DIAL 



8123 
USER^-^-^ Yes 



S125 



PRESENT PLAYBACK TIME 
SETATTHEDIVISIONBOUNDARY 



8126 



DIVISION PROCEDURE PERFORMED 
FORTHEDPLTKSRPANDTKl 



6 4/7 8 



FIG. 65 



PLAYLIST CRE ATION PROCESS INDICATED 

'S131 




.8135 



TRACK i^ELECTED USING THE CURSOR I 
KEYS SHOWN AS OBJECT FOR EDITING 



.S136 



TKACK INDICAl'KL) AS 'I'RACK THAT I 
SHOULD BE PLAYED BACK TWELTH 
IN THE PLAYBACK ORDER ' 



k+1 



S137 

1 



3138 



PlayLisUnformation COMPOSED OF 
PL_TK_SRP#1 TO #k THAT SPECIFY 
TRACKfl TO TRACKfk NEWLY 
GENERATED AND ADDED TO THE PLMG 



6 5/78 




6 6/78 



CD 

d 

I — I 

o 

P-H ^ ^ 

< w 

-a pq ^ 

< K_ W 

<^<> 




7/78 



FIG. 68 



Crecording procedu re^ • 

I _,S200 



DefaultPlaylist. TrackManager GENERATEDlj 



S201 



,S202 



AOBJilefz STORED IN THE DATA REGIONl 



-S203 



TKI#z GENERA TED AND STORED I N THE TrackManagerj 

L ^J2 04 



iDFLjrK_SRP#w GENERATED AND STORED IN THE DefaultPlayuSlNFORMATIONj 



C 



1 



.S205 



Frame_Nuinber ■ 
Data_Size-«- 0 



0VS206 



JUDGEMENT^-^^^^^ 
AS TO WHETHER INPUT OF 
THE ADTS TO BE WRITTEN INTO 
THEAOB_FILE#zIS 
XMPLETE? 



Yes 



.S209 

HAS AN AMOUNT^ _ 
IF AAC AUDIO DATA AT LEAST EQUAT 
"TTHE CLUSTER SIZE ACCUMULATE" 
INTHERAM?? 



1 



-S208 



Datajize STORED IN THE TKTMSRT 01 
THE TKI#z AS THE TKSRT_entryiy 
F0RTHEAOB_ELEMENT#y 





No 



res 



-S210 



Frame_Number Frame_Number + 1 
Data_Size *- Data_Size +DATA SIZE OF AOB.FRAME 




rS211 



Data.Size STORED IN THE TKTMSRT OF THE TKI#z I 
AS THE TMSRT_entry#y FOR THE AOB_ELEMENT#v J 




6 8/7 8 



-op 

t 



J 

I 

O 



> £X X, X, X, 



X, 

I 

■J 



i 

Xh 

5 



< 
'■2-, 

■J 



C/5 



3 

I — I 



N 

J 



3h 



X 
-J 

I 

5 



^ I 
2Q 
a., 

I 

5 



2^ 

O 
< 

I 

— H 



o 



00 



y) 



fx, 



130 

CD 



CD 

■4—1 

s 

s J 



O S 



CUE—* 
cu 
O 



cu 

< 



<jic — ' 

IS 



CD 
CO 

d 

I 1 




oo 1 — I 







ion 




rmal 


• • • 


G 

1— 1 




Flaylist 
(PLI#2) 





o 




o 



69/78 



o 

d 



Oh 




CO 

£ 

o 



X) 
Oh 



oo 



CD 

e 

CJ 
JO 



CO 



J3 



O 

J3 



CD 



CJ 



-a 

CD 

> 

cu 



CM 



CD 



CO 



C3^ 



CD 

e 



C3 



CV3 



CO 



Of, 



70/78 




71/78 



O 
0-. 



Q 

< 
O 

>^ 

o 

:z; 



Q 

<: 

w 

PQ 
O 

o 

w o 

W oo 



O 



O 

00 

D 
O 

J— 1 

> 



O 

< 

< 

Oh 
W 

CO 

w 
a: 



o 
< 

1 1 

o 
> 
< 



00 

o 





o 

00 



O 
oo 

> 

o 



o 

Q 

a: 

D 



CV] 

d 

t—H 

72/78 



FIG. 73 



PLAYBACK POSITION 
DETERMINING PROCEDU: 

, .S301 
-IICHOFTHE^ 

'PLMG_AP_PL AND PLMG_RSM_Pl? 

IS TO BE PLAYED BACK WHEN THE 

MEMORY CARD 

ISLOADEJi^ 

PLMG RSM PL 



PLMG AP PL 



,S303 



'ARE THE 
T'iaylist_Number, Track_Number 
AND Playback_Time RECORDED 
INTHEPLMG_RSM 
VALIDJi 

Yes 



,S304 



No, 



302 



REFER TO PLMG_AP_PL, SPECIFY TKI INDICATED BY 
TrackNumber IN THE PLAYLIST INDICATED BY THE 
Playlist_Number GIVEN IN PLMG_AP_PL AS TKI#z, 
START PLAYBACK FROM AOB FILE#z 
CORRESPONDING TO TKI#z 



IS THE Playback 
iTime GIVEN IN THE PLMG_RSM. 
PL EQUAL TO THE PLAYBACK PERIOD FOR 
THE Track_Number 
GIVEN 



S305 



END 



,S306 



Yes 



S307 



TKI INDICATED BY THE Track_Nuniber IN PLMG 
_RSM_PL SET L\' TKI#z 



AOB_ELEMENT#y AND AOB_FRAME#x 
SPECIFIED IN AOB FILE#z BASED ON 
Playback_Time 



^ PLAYBACK COMMENCES FROM AOB_ 
Jk S308 |fRAME#x IN AOB_ELEMENT#v OF AOB FILE#; 

ISTHETrack'""'"*-^ ^S309 
.Number IN PLMG_RSM 
PL EQUAL TO TKI_Ns IN THE 
PlaylistManager ? 



:es 



S311 



S310 



TKI FOLLOWING THE TKI INDICATED BY THE 
Track_Number IN PLMG_RSM_PL SET IN TKI#z 



PLAYBACK INDICATION OF 
NEXT PLAYLIST RECEIVED 





END 



S312 



PLAYBACK OF AOBs COMMENCES FROM THE START OF AOB FILE#z; 
CORRESPONDING TO TKI»z 



C END ^ 
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FIG. 75 





Track_ 
Number 


Playback_Time 


DefaultPlaylist.DPLGI.DPLI_RSM_PL 
Playlist#l .PLGI.PLI_RSM_PL 
Playlist#2.PLGI.PLI_RSM_PL 
Playlist#3.PLGI.PLI_RSM_PL 


TrackC 

FF 
TrackA 

00 


00:03:31.0000 

00:01:11.0000 
00 
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FIG. 77 



PLAYLIST SELECTION MENU 
SELECT A PLAYLIST FOR PLAYBACK 



DefaultPlaylistI TrackC 00:03:31.0000 



Playlist#l PLAYBACK COMPLETE 
Playlist#2 TrackA 00:01:1L0000 
Playlist#3 • • • YET TO BE PLAYED BACK 
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TEE COMISSIOIER IS AUTH0HI2ED 
TO CHAEGE MY DS^ICIEICY II THE 
FEIS FC2 THIS PAPER TO DEPOSIT 
ACCOMT HO. 23-0975 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
In re application of 

Kenji TAGAWA et al : Attn: APPLICATION BRANCH 

Serial No. NEW : Docket No. 00703/FP-2K021 

Filed May 26, 2000 

SEMICONDUCTOR MEMORY CARD, 
PLAYBACK APPARATUS, RECORDING 
APPARATUS, PLAYBACK METHOD, 
RECORDING METHOD, AND COMPUTER- 
READABLE RECORDING MEDIUM 



LETTER RE PROPOSED DRAWING AMENDMENTS 

Assistant Commissioner for Patents, 
Washington, D.C. 

Sir: 

Enclosed herewith are photocopies of Figs. 16 and 74 marked in red to indicate proposed 
drawing amendments thereto. 

The Examiner is requested to approve such proposed drawing amendments, and after 
allowance of this application, formal drawings incorporating such amendments will be filed. 

Respectfully submitted, 

Kenji TAGAWA et al. 



By f:>^ i^^U^^C^^ 
Charles R. Watts 
Registration No. 33,142 
Attorney for Applicants 

CRW/asd 
Washington, D.C. 
Telephone (202) 721-8200 
Facsimile (202) 721-8250 
May 26, 2000 
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Rev. 11-3/98 



Effective October 1997 



DECLARATION AND POWER OF ATTORNEY FOR U.S. PATENT APPLICATION 



( ) Original 



( ) Supplemental 



( ) Substitute 



( ) PCT 



( ) Design 



As a below named inventor, I hereby declare that: my residence, post office address and citizenship are as stated below next 
to my name; that Tverily believe that I am the original, first and sole inventor (if only one name is listed below) or an original, first and 
joint inventor (if plural inventors are named below) of the subject matter which is claimed and for which a patent is sought on the invention 
entitled: 

^.^ . . SEMICONDUCTOR MEMORY CM(D, PIAYBACK APPARATUS, RECOMDING APPAE^TUS, 

* ^' PLAYBACK METHOD, RECORDING METHOD, AND COMPUTER-READABLE RECORDING 



MEDIUM 



of which is described and claimed in: 
(V) the attached specification, or 
( ) the specification in the application Serial No. 
and with amendments through . 



filed _ 

. (if applicable), or 



filed . 



_, and as amended 



( ) the specification in International Application No. PCT/ 

on (if applicable), 

I hereby state that I have reviewed and understand the content of the above-identified specification, including the claims, as amended 
by any amendment(s) referred to above. 

I acknowledge my duty to disclose to the Patent and Trademark Office all information known to me to be material to patentability as 
defined in Title 37, Code of Federal Regulations, §1.56. 

I teeby claim priority benefits under Title 35, United States Code, §119 (and §172 if this application is for a Design) of any application(s) 
fcS|)atent or inventor^s certificate Usted below and have also identified bebw any application for patent or inventor's certificate havmg 
a Mfing date before that of the application on which priority is claimed: 



COUNTRY 


APPLICATION NO. 


DATE OF FILING 


PRIORITY 
CLAIMED 


""J-ft! ~ 

JapaH 


11-149893 


May 28, 1999 


Yes 


J^f Japan 


11-236724 


August 24, 1999 


Yes 


^^5 Japan 


11-372605 


December 28, 1999 


Yes 



























I hereby claim the benefit under Title 35, United States Code, §120 of any United States appHcation(s) listed below and, insofar as the 
subject matter of each of the claims of this application is not dislcosed in the prior United States application in the manner provided by 
the first paragraph of Title 35, United States Code, §112, 1 acknowledge the duty to disdose information material to patentabiHty as defin- 
ed in Title 37, Code of Federal Regulations, §1.56 which occurred between the filing date of the prior application and the national or 
PCT international filing date of this application. 



APPLICATION SERIAL NO. 


U.S. FILING DATE 


STATUS: PATENTED, PENDING, 
ABANDONED 
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And I hereby appoint John T. Miller. Reg. No. 21,120; Michael R, Davis, Reg. No. 25,134; Matthew M. Jacob, Reg. No. 25,154; 
Jeffrey Nolton, Reg. No. 25,408; Warren M. Cheek, Jr., Reg. No. 33,367; Nils E. Pedersen, Reg. No. 33,145 and Charles R. Watts, 
Reg. No. 33,142, who together constitute the firm of WENDEROTH, LIND & PONACK, L.L.P., attorneys to prosecute this application 
and to transact all business in the U.S. Patent and Trademark Office connected therewith. 

I hereby auAprize the U.S. attorneys named herein to accept and follow instructions from N^k^jima Patent 

Attorneys Office as to any action to be taken in the U.S. Patent and Trademark Office 

regarding this application without direct communication between the U.S. attorneys and myself. In the event of a change in the persons 
from whom instructions may be taken, the U.S. attorneys named herein will be so notified by me. 



Send Correspondence to Direct Telephone Calls to: 

WENDEROTH, LIND & PONACK, LX.P. WENDEROTH, LIND & PONACK, L.L.P. 

2033 K Street, N.W., Suite 800 Area Code (202) 721-8200 

Washington, DC 20006 

Direct Facsimile Messages to: 
Area Code (202) 721-8250 



Full Name of 
First Inventor 


FAMILY NAME 

Tagawa 


FIRST GIVEN NAME 

Kenji 


SECOND GIVEN NAME 


Residence & 
Ipitizenship 


CITY 

XT'— 4_ _ _ 

Katiano 


STATE OR COUNTRY 

Japan 


COUNTRY OF CITIZENSHIP 

Japan 


{Bost Office 
::|lddress 


ADDRESS 

5-5-305, Myoukenzaka 


CITY 

Katano 


STATE OR COUNTRY ZIP CODE 

Japan 576-00^1 


^ S ull Name of 
^;:Second Inventor 


FAMILY NAME 

Matsushima 


FIRST GIVEN NAME 

Hideki 


SECOND GIVEN NAME 


^litesidence & 
"Citizenship 


CITY 

Studio City 


STATE OR COUNTRY 

California, U.S.A. 


COUNTRY OF CITIZENSHIP 

Japan 


Sost Office 
m^ddress 


ADDRESS 

10989 Bluff side Dr., 
#3217 


CITY 

Studio City 


STATE OR COUNTRY ZIP CODE 

California 91604 


i #uU Name of 
.i^fhird Inventor 


FAMILY NAME 

Hirota 


FIRST GIVEN NAME 

Teruto 


SECOND GIVEN NAME 


'i^esidence & 
Citizenship 


CITY 

Moriguchi 


STATE OR COUNTRY 

Japan 


COUNTRY OF CITIZENSHIP 

Japan 


Post Office 
Address 


ADDRESS 

1-20-1-306, Kajiitiachi 


CITY 

Moriguchi 


STATE OR COUNTRY ZIP CODE 

Japan 570-0015 


Full Name of 
Fourth Inventor 


FAMILY NAME 

Ishikawa 


FIRST GIVEN NAME 

ToiTiokazu 


SECOND GIVEN NAME 


Residence & 
Citizenship 


CITY 

Toyonaka 


STATE OR COUNTRY 

Japan 


COUNTRY OF CITIZENSHIP 

Japan 


Post Office 
Address 


ADDRESS 

4-6-14, Sanwacho 


CITY 

Toyonaka 


STATE OR COUNTRY ZIP CODE 

Japan 561-0828 
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Ful l Name of 
Fifth Inventor 


FAMILY NASIE 

Inoue 


FIRST GIVEN NAME 

Shinji 


SECOND GIVEN NAME 


Residence & 
Citizenshin 


CITY 


STATE OR COUNTRY 
.'TaT\an 


COUNTRY OF CITIZENSHIP 

.Tartan 


Post Office 
Address 


ADDRESS 

19-1-1142, iyiatsuyacho 


cmr 
Neyagawa 


STATE OR COUNTRY ZIP CODE 

Japan 572-0086 






Fu!l Name of 
Sixth Inventor 


FAMILY NAME 

Koziika 


FIRST GIVEN NAME 

Masayuki 


SECOND GTVEN NAME 


Residence & 
Citizenship 


cmr 

Arcadia 


STATE OR COUNTRY 

California, U.S.A. 


COUNTRY OF CITIZENSHIP 

Japan 


Post Office 
AQoress 


ADDRESS CITY STATE OR COUNTRY ZIP CODE 

501 Coyle Avenue, Arcadia, California 91008 






Full Name of 
Seventh Inventor 


FAMILY NAME 


FIRST GIVEN NAME 


SECOND GIVEN NAME 


Residence & 
Citizenship 


CITY 


STATE OR COUNTRY 


COUNTRY OF CITIZENSHIP 


Post Office 
Address 


ADDRESS 


CITY 


STATE OR COUNTRY ZIP CODE 





Vf^J further declare that all statements made herein of my own knowledge are true, and that all statements on information and belief are 
bMfeved to be true; and further that these statements were made with the knowledge that willful false statements and the like so made are 
pMshable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that such willful felse 
stjlements may jeopardize the validity of the a5>plication or any patent issumg thereon. 



Isljlnventor . 
2fi^, Inventor . 
311: Inventor . 
4ffiilnventor . 
Ste Inventor . 



5^f Inventor ^rM^-H^^ . J^^Tz^^-'-H.J^ 
6th Inventor _ 



7th Inventor , 



Date May 


8, 


2000 


Date May 


8, 


2000 


Date May 


8, 


2000 


Date May 


8, 


2000 


Date May 


8r 


2000 


Date May 


8, 


2000 
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